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:
; charset=UTF-8\’); ?>
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. After some searching, APIs Explorer on developers.google.com caught my attention. Google’s APIs Explorer is a tool that helps you to explore various Google APIs interactively. Google also says that with the APIs Explorer, you can browse quickly through available APIs and versions, see methods available for each API and what parameters they support along with inline documentation, etc. 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:
The Base parameter is filtered by certain regular expressions (not quite accurately though) but it is easy to bypass them using a %23 symbol:
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.click’ to my exploit after creating the documentation link via postMessage. Symbols [ and ] were filtered, so actually the callback was as follows:
Let’s try it:
Done! Works fine and no need for user interaction. The exploit was as follows:
token_1 = location.hash.split(\’rpctoken=\’);
token_2 = window.name;
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 to be able 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.
Author: Pavel Toporkov, Positive Research