Cenzic 232 Patent
Paid Advertising
web application security lab

Clickjacking Details

Today is the day we can finally start talking about clickjacking. This is just meant to be a quick post that you can use as a reference sheet. It is not a thorough advisory of every site/vendor/plugin that is vulnerable - there are far too many to count. Jeremiah and I got the final word today that it was fine to start talking about this due to the click jacking PoC against Flash that was released today (watch the video for a good demonstration) that essentially spilled the beans regarding several of the findings that were most concerning. Thankfully, Adobe has been working on this since we let them know, so despite the careless disclosure, much of the work to mitigate this on their end is already complete.

First of all let me start by saying there are multiple variants of clickjacking. Some of it requires cross domain access, some doesn’t. Some overlays entire pages over a page, some uses iframes to get you to click on one spot. Some require JavaScript, some don’t. Some variants use CSRF to pre-load data in forms, some don’t. Clickjacking does not cover any one of these use cases, but rather all of them. That’s why we had to come up with a new term for it - like the term or not. As CSRF didn’t fit the requirements for clickjacking, we had to come up with a new term to avoid confusion. If you like Michael Zalewski’s term “UI redress attack” better use that one, it’s just not CSRF and shouldn’t be mistaken for any other attack, since it really is different. Here is the technical detail:

Issue #1 STATUS: Unresolved. Clickjacking allows attackers to subvert clicks and send the victim’s clicks to web-pages that allow themselves to be framed with or without JavaScript. One-click submission buttons or links are the most vulnerable. It has been known since at least 2002 and has seen at least three different PoC exploits (Google Desktop MITM attack, Google Gadgets auto-add and click fraud). All major browsers appear to be affected.

Issue #1a STATUS: Unresolved. JavaScript is not required to initiate the attack as CSS can place invisible iframes over any known target (EG: the only link on the red herring page). Turning off JavaScript also neuters one of the only practical web based defenses against the attack which is the use of frame busting code.

Issue #2 STATUS: Unresolved. ActiveX controls are potentially susceptible to clickjacking if they don’t use traditional modal dialogs, but rather rely on on-page prompting. This requires no cross domain access, necessarily, which means iframes/frames are not a prerequisite on an attacker controlled page.

Issue #2a STATUS: To be fixed in Flash 10 release. All prior versions of Flash on Firefox on MacOS are particularly vulnerable to camera and microphone monitoring due to security issues allowing the object to be turned opaque or covered up. This fix relies on all users upgrading, and since Flash users are notoriously slow at upgrading, this exploit is expected to persist. Turning off microphone access in the BIOS and unplugging/removing controls to the camera are an alternative. Here is the information directly from Adobe.

Issue #2b STATUS: Unresolved. Flash security settings manager is also particularly vulnerable, allowing the attacker to turn off the security of Flash completely. This includes camera/microphone access as well as cross domain access. Resolved using frame busting code, bug #4 below notwithstanding. However, as pointed out elsewhere, it is possible to directly frame the SWF file example here and here.

Issue #2c STATUS: Fixed in Flash 10 release. All versions of Flash on IE7.0 and IE8.0 could be overlayed by opaque div tags. Using an onmousedown event handler the object click registers as long as the divs are removed by the onmousdown event handler function. Demo here of stealing access to the microphone.

Issue #3 STATUS: To be fixed in the final release candidate. Flash on IE8.0 Beta is persistent across domains (think “ghost in the browser”). This would be a much worse vulnerability except for the fact that it is beta and almost no one is using it.

Issue #4 STATUS: To be fixed in the final release candidate. Framebusting code does not appear to work well on some sites on IE8.0 Beta. Instead it is marked as a popup which is blocked by the browser - disallowing the frame busting code from executing.

Issue #5 STATUS: Unresolved. State of clicks on other domains can be monitored with JavaScript (works best in Internet Explorer but other browsers are vulnerable too) which is cross domain leakage and can allow for more complex multi-click attacks. For example a page that has a check box and a submit button could be subverted upon two successful clickjacks. Additionally, this can make the attack completely seamless to a user by surrendering control of the mouse back to the user once the attack has completed.

Issue #6 STATUS: Unresolved. “Unlikely” XSS vulnerabilities that require onmouseover or onmousedown events on other parts of pages on other domains are suddenly more likely. For example if a webpage has a XSS vulnerability where the only successful attacks are things like onmouseover or onmousedown, etc… on unlikely parts of the page, an attacker can promote those exploits by framing them and placing the mouse cursor directly above the target XSS area. Therefore, otherwise typically uninteresting or unlikely XSS exploits can be made more dangerous.

Issue #7 STATUS: Fixed in current releases post 1.8.1.9. Firefox’s Noscript plugin’s functionality to forbid iframe’s can be subverted by iframing a page that contains a cross domain frame or as Ronald found by using object tags. Giorgio Maone validated the issues and issued patches in future releases of the code as well as other potential clickjacking mitigation. 1.8.1.6, 1.8.1.7, 1.8.1.8, 1.8.1.9, 1.8.2 and 1.8.2.1 all contain anti-clickjacking code. All prior versions to 1.8.1.9 were vulnerable to cross domain clickjacking.

Issue #8 STATUS: Unresolved. Attempts to protect against CSRF using nonces can often be overcome by clickjacking as long as the URL of the page that contains the link that includes the nonce is known. Eg: Google Gadgets exploit discussed in Blackhat “Xploiting Google Gadgets” speech. The only semi-decent defenses against this are to omit the nonces in JavaScript space and also include the frame busting code in the same JavaScript. This will break for users who do not use JavaScript though, so it is not an ideal solution.

From an attacker’s perspective the most important thing is that a) they know where to click and b) they know the URL of the page they want you to click, in the case of cross domain access. So if either one of these two requirements aren’t met, the attack falls down. Frame busting code is the best defense if you run web-servers, if it works (and in our tests it doesn’t always work). I should note some people have mentioned security=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials.

Thanks to Adobe, Microsoft, Firefox, Apple and the various other vendors and people who have been helpful/supportive and care to fix the issue. Also thanks to the researchers who found these issues independently after Jeremiah and I were unable to do our speech, but kept it to themselves (Arshan Dabirsiaghi, Jerry Hoff, Eduardo Vela, Matthew Matracci, and Liu Die Yu). The clickjacking overview whitepaper has been released here. Source to generic clickjacking code available here. I will keep this post up to date with additional issues and updates as I am aware of them.

42 Responses to “Clickjacking Details”

  1. Giorgio Maone Says:

    @RSnake:
    Did you check out NoScript’s new feature, called ClearClick?
    It’s meant to prevent clickjacking/UI redressing without the strict need of blocking frames or plugin content, or even disabling JS (of course, the more the layers the better):
    http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/

    It should also be noted that NoScript 1.8.2 and above allow frame busting code to work as intended even on pages where JavaScript is disabled (”Frame Break Emulation”).

  2. kuza55 Says:

    Any chance of details on how the Flash security manager has been ‘fixed’? Has the functionality to disable SOP enforcement simply been removed/neutered?
    The page at http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html looks like it always has, and I’m honestly a bit too lazy to look through thousands of lines of actionscript to find out if anything has changed (given I only had the foresight to download the swf yesterday)

  3. sirdarckcat Says:

    They are fixing this server-side (check out the source code).
    script type=”text/javascript”
    // ![CDATA[

    if (top!=self){
    top.location.href=self.location.href;
    }

    BTW, NoScript doesnt breakes iframe-breakes anymore :)

    ¬¬

    Greetz!!

  4. kuza55 Says:

    @sirdarckcat:
    /facepalm

  5. monyer Says:

    @sirdarckcat:

    var location=”";

    can Bypass.

  6. Scott Johnson Says:

    Your link to generic cj code is giving an internal server error.

  7. RSnake Says:

    @Scott - sorry about that. Updated the link.

  8. Sisupoika Says:

    I too - as many - have been following your updates out of great curiosity, but as many of the issues you are sheding light on have mostly been known for years in a way or another, I must confess that I am a bit disappointed :D

    Just kidding.
    The tricks which affect Flash are alone a good enough reason for a
    responsible disclosure, and I believe we all are thankful for this.

    But after all that has already been said for days regarding these issues, and especially the ones concerning iframes, etc. am I the only one surprised that no mention has been made yet of P3P and what is was supposed to be /represent?

    There is no need for iframes and overlays and so on if this “Clickjacking” (I prefer “UI redressing though :D) targets websites which would require access to cookies.

    Also, who’s gonna make the next PoC, with Java applets? :D
    Why has P3P been completely forgotten and/or ignored?

  9. Sisupoika Says:

    (I meant “which would NOT require access to cookies.”)

  10. Scott Herbert Says:

    “They are fixing this server-side (check out the source code).
    script type=”text/javascript”
    // ![CDATA[

    if (top!=self){
    top.location.href=self.location.href;
    }

    Surely that would look like a 302 redirection scam to webspiders and result in your site being banned from them.

    Wouldn’t

    script type=”text/javascript”
    // ![CDATA[

    if (top!=self){
    self.location.href=”http://domain.com/clickjack.html”;
    }”

    Work better?

  11. IU Says:

    So far, all that has been discussed is clicks. Could this same clickjacking concept not be used to implement “typejacking” (i.e. a keylogger)?

    Say the attacker was able to use a transparent IFRAME to track a user from search engine to financial site. Could the IFRAME not then be used, as a keystroke logger, to capture the user’s typing?

  12. David Walker Says:

    Issue 5: “completely seemless” is the opposite of what you probably mean.

  13. x-tense Says:

    @IU

    Sure you can ;)
    you must create a transparent div with textarea and input at the same position of the iframed web site.
    If you are interested, I’ll post this PoC soon ;)

  14. roflem Says:

    excellent! I was told to be paranoid when my macbook was hijacked via such a script attack from russia. Now its official and fixes are not in sight.
    my momentary worry: TR-069. These guys are so ahead of all of us, its almost amazing

  15. x-tense Says:

    @IU

    I finished it and I’ll host the PoC tomorow. However, “typejacking” like you said, is more a “phishing” attack.
    Indeed, to exploit a clickjacking attack you must control the HTML of the webpage, so if you can, why trying “typejacking” insteed of creating a fake form ;) ?

  16. RSnake Says:

    @x-tense - some things might work regardless of phishing. But that comment reminded me of something I had meant to post. Some people have said “if I stayed logged out…” Yes, but let’s hope they are also not using any programs that auto-fill passwords and I can’t get them to click on submit for me.

    @David Walker - completely seemless is exactly what I mean. It can give control back to the user and send them onto the link they think the pressed, allowing them to believe nothing happened.

  17. IU Says:

    @x-tense: Thanks

    This is a pretty nasty flaw indeed.

  18. x-tense Says:

    The PoC “typejacking” is hosted here: http://xmcopartners.com/actu-secu/21/poc/typojacking-gmail-en.html

    (tested with IE and Firefox with 1024×768 and 1280×1024 resolution with an english version of gmail)

    You must be logged out of gmail

  19. Arkh Says:

    Maybe the browsers could send some headers to pages in frames so targets could do something even without javascript. Or are there already which website owners should be aware of ?

  20. Matthew Mastracci Says:

    Since the cat’s out of the bag, I may as well show off my version:

    http://grack.com/record

    It uses some JS to dynamically wrap the flash object.

  21. rvdh Says:

    @x-tense

    That’s just phishing, and no need to load the original page, cust copy the HTML and your done.

  22. x-tense Says:

    @rvdh
    That’s why I said the typejacking is more a “phishing” attack. I just created a poc to illustrate this.
    If you see an other idea to exploit it I’m aware :)

  23. kokomo Says:

    Here is an idea for a fix. Why don’t the web browsers provide a 3D view of a web page. Separate all the layers (whether visible or not), and find out what exactly you are clicking on. This 3D view can be as simple as a mouseover with a small window showing the multiple layering that is taking place on a page. How practical is it? I don’t know, but it seems to me that it would be the only ultimate solution possible.

  24. pwndomina Says:

    very interesting technique however the video showed it requires a lot of user interaction

  25. RSnake Says:

    @pwndomina - that variant does, yes. Many variants only require one or two clicks to do the same thing.

  26. kuldeep Says:

    click jack is major threats to all the types of browsers..
    article lacks this current scenario i.e how clickjack plays it’s
    impacts on browser.

  27. Xain Says:

    @Matthew Mastracci

    The one which u posted shows Adobe security option which informs the user that the applications is trying to access user’s camera so it is not an exploit

  28. ortdx Says:

    Flash Player 10 is also affected by this vulnerability?

  29. Spelling B Says:

    @RSnake - “completely seemless is exactly what I mean. It can give control back to the user and send them onto the link they think the pressed, allowing them to believe nothing happened.”

    Indeed, though “seamless” not “seemless” is precisely what you mean.

    Sorry :)

  30. rvdh Says:

    @Xain @kuldeep @pwndomina:

    http://www.0×000000.com/?i=317

    Goodluck downplaying it again next time. ;)

  31. Mahavir sancheti Says:

    http://www.csoonline.com/article/455072/Adobe_Fixes_Clickjacking_Flaw

  32. Jeremy Says:

    Ok - clickjacking bad… got it. How do sites protect there users…

    Encrypted/Random URLs? sure this is possible.

    Framebreaker - good idea to put one on your page… However, framebreaking code could be stopped in IE if someone were to use security=restricted or had javascript turned off. So what about in addition to a framebreaker include a noscript tag to cover up the pages content:

    this page requires javascript

    Anyone see a problem with that? Other then usability by people who disabled JavaScript…

  33. Jeremy Says:

    Ok the noscript element in my above post was suppose to be:

    <noscript><div style="position:absolute;left:0;top:0;z-index:99;width:10000;height:10000;">This page requires JavaScript</div></noscript>

  34. RSnake Says:

    The paper has been re-posted here: http://www.sectheory.com/papers.htm for those of you who can’t/didn’t sign up for Hackers for Charity.

  35. KoRny Says:

    @Jeremy: Wouldn’t it be better to just set the width and height to 100%? Additionally, if you want to use something like this, my thinking is to be effective you should setup a background color to mask the contents completely.

  36. Jeremy Says:

    When I originally thought of doing the div to block the content I thought it would be best use a 1×1 semi-transparent PNG tiled over the background to “grey” out the contents of the site.

    And yes, the height and width being set to 100% would work also - I choose an arbitrarily large value incase there was some wierd rendering bug in browser ??? that I wasn’t aware of ;)

  37. pwndomina Says:

    @rvdh - you summarized the attack on a very simple way =)
    i have a question regarding the same origin policy, i read/remember sometime ago, the settings of internet explorer for SOP differed when a document was opened locally or opened remotely(internet and local intranet?), this still happen on IE7.0?
    also if possible can you provide further information/explanation about cross-domain acess?
    thank you

  38. pwndomina Says:

    @RSnake - can you clarify this questions? i would appreciate.
    also if possible can you provide the contact of rvdh since i dont find any on his webpage?
    thanks.

  39. Tom Brennan Says:

    The OWASP Foundation is deeply concerned about the risks associated with increasingly useful and powerful browsers. We are seeking to support browser vendors on these issues with our research, resources and ideas. To this end, the OWASP Intrinsic Security Working Group (ISWG) has identified an initial list of the most important risks and recommendations:

    Phishing
    Malware
    Reflected Cross-Site Scripting
    Runtime Profiles
    Clickjacking
    Policy-based Content Restrictions
    Policy-based JavaScript Capabilities
    OS Process Isolation
    Security Zones
    SSL EV Certificate Support

    and more …

    To get involved and for more information on the 100% volunteer effort happening at OWASP Foundation visit: http://www.owasp.org/index.php/OWASP_Working_Session_-_Browser_Security

  40. Abe Says:

    Another serious flaw in a few weeks.

    The nature of css, dhtml and other current web design trick allow for more complex ways of creating a rich user experience.

    So this probably won’t disappear any time soon.

    I can think of several ways to get around the Iframe restrictions…

    Another great post RSnake ;)

  41. Ananta Arun Says:

    Hi,
    I am doing a paper on ClickJacking. I was wondering if I quote your report in my paper. Please respond as soon as possible as I have to submit the paper soon. You can contact me at poolla.mit@gmail.com. I will be really glad to hear back from you. Thank you.

  42. alex@zczczc Says:

    This is the first time for me to hear about ClickJacking. I’m not an expert in web or IT, so thanks to you, I have more knowledge about it. However, how can I avoid being a victim for some issues that you write still unresolved?