Saturday, June 8, 2013

Flash based XSS in Yahoo Mail

I discovered a XSS vulnerability in IO Utility [1] of YUI library. In this post I explained the vulnerability and it's affect on Yahoo Mail.  

The ExternalInterface class in ActionScript is an application programming interface that enables communication between ActionScript and the SWF container. This class has a method named "call()" which invokes a JavaScript function if the container is a HTML page. It takes two parameters, the first one is the name of the JavaScript function to call and the other one is a string to pass to that JavaScript function. It is possible to execute malicious JavaScript in context of container if one of these parameters are attacker-controlled [2].

In IO Utility of YUI, io.swf (located at yui\build\io-xdr\io.swf) was vulnerable to XSS. As you can see in figure 1, yid and uid are derived from user input and then used as a parameter in without any validation. 
Figure 1 - Vulnerable code
By this vulnerability attacker could execute malicious JavaScript in context of io.swf container.

Yahoo Mail was affected by this vulnerability because, io.swf was hosted at Yahoo mail main domain (fail!) and accessible from for logged in users.

Figure 2 - io.swf hosted in Yahoo Mail domain

How to exploit this issue:
Yahoo uses HTTPOnly flag for cookies so it's not possible to hijack cookies but as io.swf is hosted in context of us-mg[x] I was able to execute JavaScript in context of us-mg[x] For example by sending below URL to a Yahoo Mail user it was possible to read his inbox.\%22%29%29;}catch%28e%29{'');setTimeout('alert(x.document.body.innerText)',4000)}//
In a future post I'll explain the exploitation of this type of vulnerabilities. 
PoC Video:

June 6th, YUI 3.10.1 released which fixed this issue. Fix is based on a regular expression which validates the yid and uid value.
Figure 3 - Vulnerability fixed
Yahoo Security team response:
I was aware of this vulnerability for a long time but I didn't interested to report it to Yahoo Security because my past experiences shows that nothing more than a T-shirt could be achieved (they don't send it to Iran :P), even no credit for responsible disclosure when you report a vulnerability to Yahoo! 

However recently I sent an email and asked if they pay reward for responsible disclosure and they replied:
Figure 4 - Yahoo Security team response


Tuesday, April 30, 2013

Exploiting an unexploitable persistence DOM based XSS in by using root domain cookies!

I found a persistence DOM based XSS vulnerability in website. As it was not possible to exploit it directly without altering the cookies, I called it an unexploitable vulnerability! However, I could exploit it by using another XSS vulnerability which was in s3 subdomain of website. This post explains what I have done to exploit this issue.

DOM based XSS in
First I found a DOM based XSS in As you can see in below picture the source is a cookie (feedlyVersion) and the sink is document.write(). 

Figure 1 - Picture of vulnerable code
Normally we can't exploit this issue because it's not possible to control the value of 'feedlyVersion' cookie and this is a less severe issue.

But in this type of vulnerability if attacker can control a cookie in a victim’s browser, then it can be assumed that exploitation is similar to other vectors where an attacker controls aspects of a user request, like a querystring value, or an HTTP POST name-value pair [1]. So the only way to exploit this DOM based XSS was adding a new cookie with the same name as 'feedlyVersion' and our payload.

Flash based XSS in
Then I tried to find another XSS vulnerability in sub-domains. Quickly I found a vulnerable version of JWplayer [2] ( in 

Figure 2 - Flash based XSS in
Figure 3 - befor adding new cookie
Through this vulnerability in subdomain It was possible to add a new cookie for * 

Chaining these issues:
To successfully exploit this issue our new feedlyVersion cookie should be in front of original feedlyVersion in cookie string. I used the trick which Egor Homakov introduced in his "Hacking Github with Webkit" blogpost [3].

A) Set a new cookie with feedlyVersion name and our payload for *
B) Moving our new feedlyVersion in front of the old one in cookie string:'');x1.close();
C) Redirecting user to to execute our payload:
Finally putting all of them together:{document.cookie="feedlyVersion='><script>prompt(document.domain)</script>;;Path=/;";'');x1.close();location.href=''}
Figure 4 - before adding new feedlyVersion cookie
Figure 5 - after adding feedlyVersion cookie (by attacker)
Figure 6 - after adding new feedlyVersion cookie
Figure 7 - Attacker controlled cookie delivered to the sink

PoC Video:

Disclosure Timeline:
April 8, 2013: Details of the vulnerabilities sent to Feedly.
April 8, 2013: Received reply, "Will take a look at them today".
April 9, 2013: Received reply, "All issue have been fixed".

Kudos to the Feedly team for fixing issues very quickly.