Here are some writeups of few bugs I found in Yandex services last time.
1) Reflected XSS in http://interactive-answers.webmaster.yandex.com.
HTTP/1.1 200 OK
Date: Thu, 17 Apr 2014 17:13:57 GMT
Content-Type: text/html; charset=utf-8
As you can see - it’s html document. As far, as we are able to control part of response content and it’s unescaped - it would render as normal html. That’s typical XSS. JSON contains GET filename parameter unescaped, controlled by us. The Proof of Concept would look like this:
<form method="POST" enctype="multipart/form-data" action="http://interactive-answers.webmaster.yandex.com/gate/add-scheme/get?crc=uc52c5955b971de4d17729378417f305d&filename=b<script>alert(1);</script>">
<input type="file" name="f"> <!-- just in case -->
2) Stored XSS in Yandex Maps Constructor (http://api.yandex.ru/maps/tools/constructor/)
URL decoded map parameter looks this way:
Those two XSS were duplicates. Also as you can notice, both are unexploitable without having CSRF token (in my case: uc52c5955b971de4d17729378417f305d). That’s why I want to introduce...
3) Same-Origin Policy bypass I was working to find out how steal this token. At first I noticed, that the same CSRF token is used in multiple services (of course different tokens for different users ;)). One of places where this token appears in source code is Yandex Maps. After many days of trying to somehow get secret key - I checked crossdomain.xml. It's a special file used by Flash or Java for Same-Origin Policy purposes. Here’s how it looks for maps.yandex.com:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<!-- vim: set ts=4 sw=4 et: -->
It means, that Flash application hosted on any domain from above is able to send requests (with credentials) to http://maps.yandex.com and also gain full response content (the same that browsers renders for authenticated user). The problem was that I didn’t had possibility to upload my specially prepared SWF file to be hosted on any of this domains. After lots of research and analysis of swf files hosted on those domains, I found one interesting:
Now - servantUrl determine from where data should be loaded. Application make two requests - first one:
...which is XML file. As far as this service (kraski) is not working anymore, I had to determine how the XML file should looks like, to execute my own flash :) Effect:
<?xml version="1.0" encoding="UTF-8"?> <card picturesTotal="1" v="1.0"> <visual type="Picture"> <content>Q1dTDgoFAAB42l1TzW7b(........)TxP9U4ZKU=</content> </visual> </card>
The <content> node contains base64 encoded swf binary - kraski-universal-blogplayer decodes it, and loads using loader.loadBytes(). The source for my flash looks like this:
1. Victim visits malicious site (ropchain.org)
2. Attacker puts there <object> with kraski-universal-blogplayer
3. Victim click on ‘play’ button.
6. Attacker exploits both XSS issues, because now he know secret-key value :) (as far as first one is reflected XSS - it cannot be exploited on browsers that uses some Anti-XSS mechanism, but the second one works fine on all modern browsers. That is why on video I’ll show later only one alert will apear (as far as I'm Chrome user).
Of course - it’s not the end. :) Bypassing Same-Origin Policy can be exploited in worst scenario, because mail.yandex.com have the same crossdomain.xml file. ;-) So attacker is able to read sensitive data such as: user login, user phone number, list of contacts, e-mail subjects and content. Every domain that Yandex own and have similar crossdomain.xml file - is vulnerable to this attack. In mail.yandex.com there are two interactions that victim need to do - first is accept certificate for kraski-static.yandex.net, and second is to click “Play” button.
Second exploit: https://gist.github.com/ZoczuS/c8abb829237cb178d364
And at the end - video demonstration for stealing CSRF token and user e-mails: