Exploiting the unexploitable XSS with clickjacking

The technique is listed as a contestant in Top 10 Web Hacking Techniques of 2011 poll.


Clickjacking needs some loving. Contrary to what is being thought, it's not only used for Facebook viral scams. As shown by last year's Paul Stone's studies, now it's not only just hide-the-button-and-follow-the-mouse trick. It even got the more accurate name of UI Redressing (which is right, as attackers are not after your clicks, they profit from playing with the UI of the victim application). In this post we'll play a game to see how advanced UI-Redressing attacks look like and how an attacker may trigger an unexploitable XSS flaw in an application.

A box of tricks

UI-Redressing consists of several techniques that are glued together to form an attack. These techniques include:

• sending mouse clicks to victim app (classic)
• capturing keystrokes (strokejacking) 
• making an iframe follow the mouse (cursor tracking)
• making an invisible iframe
• showing only a certain small part of a web page in a frame
• dynamically positioning content in iframe
• probing for elements existience within framed document
• dragging a text out of an application
• dragging a text into an application
• faking a cursor position (cursor jacking)

Combining these tricks an attacker can build a successful attack page - it's easy and it happens everyday with Facebook 'likejacking' pages. You can read more about the internals in Marcus Niemietz's whitepaper.

/ignore same-origin-policy

What makes UI-Redressing attacks so powerful is that most of these techniques bypass Same Origin Policy restrictions. For example - you can embed an iframe from foreign domain and click will reach that iframe.
Some rely on tricks to circumvent SOP - e.g. you can read scrollTop of  foreign iframe and that allows you to probe the document that should be unreachable. Some browser vendors apply blocking security patches for a few of mentioned vectors, but in general, SOP doesn't apply.

User intervention

However, all UI-Redressing attacks require user intervention. He has to click, type, drag, sometimes several times. Getting user to click on something is not that hard, but getting him to drag or type requires a bit of social engineering - like a game. So - let's play a little game.

XSS self-injury

There's a vulnerable application here. Let's say that an attacker is after a super-secret login name of targetted user. The app has an obvious XSS flaw in the stock symbol field:

goog<script>alert(1)</script>

will trigger the flaw.
But, it's an AJAX application. There is no form that is submitted. The vulnerable parameter is not in the URL, not in the POST parameter - attacker cannot trigger the flaw (unless MITM). It can only be manually entered by user. So the only threat is that a user will craft XSS payload that will own himself. Weak... But there's always clickjacking!

The game

Let's play Alphabet Hero!

Requirements (as of today): Firefox (disable NoScript) / Safari

• Opera / IE don't work because I'm lazy and coding for them is a PITA
• Chrome doesn't work because of this patch.

Objective: How fast you are in finding letters? Let's see!

Play Alphabet Hero

Behind the scenes:
What you're really doing is, after a few decoy letters you drag the XSS payload into the vulnerable app and press 'Search'. See for yourself:

Suddenly the unexploitable XSS can be easily triggered. Invisible, cross domain, with CSRF tokens - fully legit. Clickjacking - the only winning move is not to play.

What can I do about it?

• Developers: Use X-Frame-Options and Javascript/CSS framebusting - it's that easy!
• Users: use Chrome, NoScript, pay attention to all games, especially weird mouse behaviours, cursors.
• AppSec guys: Convince browser vendors to disable cross-origin drag&drop. Chrome already did it, Mozilla considers - Vote for https://bugzilla.mozilla.org/show_bug.cgi?id=605991 and https://bugzilla.mozilla.org/show_bug.cgi?id=639796 (if you have access).