Internet Security

Home

Consulting

Papers

News

About

Bios

Contact

Cl i ckjacki ng
By Robert Hansen (SecTheory) & Jeremiah Grossman (WhiteHat Security) Date: 09/12/2008 Overview: Typically there is one type of attack - cross site request forgeries (CSRF) that can interact with functions on other websites. The primary defense against CSRF is to create one time tokens (nonces) that are placed on the page and validated on supplemental pages, to ensure that the browser indeed picked up the nonce. Nonce evasion requires that the browser somehow gains access to data in another domain. Barring any client side vulnerabilities, reading cross domain is supposed to be disallowed by virtue of the browser's same origin policy. Clickjacking, however, evades the need for this cross domain reading, and instead directly places the mouse over the target area to click on the link or form that contains the nonce - thereby bypassing the need for client side cross domain read exploitation. Scenario: Let's assume there exists a website that may be of significant importance to an attacker and a user who has access to that same domain. Let's also assume that an attacker can lure someone into visiting a page that is under the attacker's control, so that they can render JavaScript and multiple pages. There are a number of different tactics for an attacker to understand if people are authenticated to other domains and thus is slightly outside the scope of this paper. However some include the CSS history hack, the JavaScript XML error issue and so on. For example one such page than attacker may be interested in is the Adobe Global Settings Manager that controls security functions for the Adobe Flash player. A user is not required to authenticate to this site, and it is always the same URL, making it easy for demonstration purposes. In particular the attacker wants the victim to click on the "Always allow" option button on the security settings tab.

www.sectheory.com/clickjacking.htm

1/6

To understand the attack, let's dissect the various components. First the attacker starts with the target URL:

Next the attacker places that within an iframe, where the exact X and Y coordinates of the frame place the target location in the upper left hand corner of the page. The purpose of this step is to
www.sectheory.com/clickjacking.htm 2/6

make sure the location of the target link or button is in exactly the right place, regardless of the size of the window or where the target link or button is located to make the attack work more generically across multiple vulnerable websites, given that the location of the vulnerable link or button may vary from page to page:

Next this page is framed within the page that the user actually sees. The iframe is small enough to encapsulate the exact target link in a way that only it is constrained, and the rest of the page is outside of the boundary of the iframe:

Lastly the iframe is made to hover beneath the mouse pointer, so that no matter where the mouse is located it will be in the exact correct location. Final touches include turning down the opacity of the surrounding <div> tag that contains the iframe, so that it becomes invisible to the naked eye (it is left visible below for demonstration purposes - also the other frames are hidden from view normally, but left in place to see their relative location):

www.sectheory.com/clickjacking.htm

3/6

Click fraud is another great example of where clickjacking can be extremely useful. While traditional click fraud requires a large group of disparate IP space with diverse browser signatures, clickjacking provides exactly that. Since it is subversive, it can allow click fraud to occur easily, while bypassing many of the previous click fraud detection systems put in place. Varying the number of impressions verses click-throughs and the referring URLs appears to be the only major hurdle left to the would be click fraudster. This variant of clickjacking has been talked about for some time. Users of Adobe Flash player are perhaps the most at risk of compromise not just by the settings manager issue mentioned above, but also by the fact that stolen clicks can be used to enable both cameras and microphones:

By using clickjacking an attacker can create a circumstance where the victim is subversively giving access to the attacker to both listen in and view the victim on their own microphone and camera. This information can be seen in real-time by the attacker or recorded for offline viewing. Other vulnerabilities within Flash may also be possible using this tactic as well. There are certain limitations within Flash that make it difficult to hide it while the warning is visible, but this can be subverted by waiting until the last moment before making the warning visible (Eg: subverting the second click in a double-click scenario). Detecting a successful clickjack may not appear at first glance to be a particularly useful thing to an attacker. One may argue that once someone has clicked the damage is done and an attacker doesn't care if it wasn't successful. Sometimes this may be true, but there are two very important reasons it may be important to understand that something has been clicked. The first is that for stealth reasons the attacker may want to free the mouse to interact with the page once the damage is complete to reduce the likelihood of detection. The second is because clickjacking can be chained together. That is, if a successful attack relies on multiple clicks detection can alert the attacker's code to re-position the underlying frame to being in the correct position. Clickjack detection is complex and varies between browsers. In Internet Explorer an attacker can use the onclick event handler on the iframe, regardless of the fact that it is detecting interaction between the user and another domain, which typically violates the same origin policy. In Firefox an attacker can use the onblur event handler which is less accurate than the Internet Explorer method since a user may simply alt-tab away or click on the surrounding browser chrome (not to be
www.sectheory.com/clickjacking.htm 4/6

confused with Google Chrome). Either way, this is not a perfect method of detection since it is across domain, and there is no perfect way for an attacker to know (outside of other vulnerabilities) that a user has performed the action, or indeed even has Flash instantiated on the other domain, etc... Other esoteric advantages of clickjacking surround client side vulnerabilities like cross site scripting. In particular there are a number of websites that may not be vulnerable to automatic script execution, but rather rely on someone interacting with a very unlikely part of the page, or hovering their mouse over an image that is outside of the normally viewable area. Clickjacking legitimizes these bugs by placing the mouse directly over the target area, thereby instantiating the vulnerability in the other domain. Annoyances could also be created due to popup blockers that rely on mouse clicks to circumvent them. There has already been a number of clickjacking exploits found against real world applications beyond those listed. One of which was found against Google Desktop in May of 2007, which allowed an attacker to run commands on a victim's computer. This situation combined a man in the middle attack with clickjacking. Future concerns: There are a wide variety of sites that use nonces to protect themselves from CSRF attacks that would be vulnerable to this type of attack. Some of these include sites like Digg.com, who have intentionally tried to protect themselves. But there are many other sites, like Google, Microsoft and many other large enterprises that have done sufficient work to protect themselves from CSRF but are still vulnerable via clickjacking, in the absence of a way to de-frame themselves. As de-framing all critical websites everywhere is categorically a non-starter, this immediately points to the necessity for a future browser solution to the problem. Other potential issues are embedded ActiveX controls that have access to the desktop, like Webex, and Meetingplace could theoretically cause complete desktop compromises. Complex client side applications that require clicking to interface with them (Java applets for instance) could also become vulnerable. Many routers and firewalls that have recently been upgraded to protect themselves from CSRF may also be vulnerable to router resets, and other dangerous functions based on clickjacking vulnerabilities. Also, Firefox plugins like Flashblock that may require a user click to enable objects could also become under attack. This will make upgrading browser plugins more critical, because selective object instantiation may be subverted by clickjacking:

www.sectheory.com/clickjacking.htm

5/6

Forced downloads of executables on certain browsers may be possible in certain browsers, although the path to exploitation may be more complex or may involve ActiveX issues provided by tools that control the desktop as mentioned previously. It's unknown as to the true extent that this vulnerability class allows as to how it will effect CSRF issues in the future. Mitigation Issues: The best way to protect a website, currently is to use frame busting scripts, as are found on a great number of websites. However, because of browser security functionality like the security=restricted tag in Internet Explorer, frame busters can be turned off by the parent frame. Combining these frame busting scripts with other more integral functionality to the CSRF protections can limit the usefulness of the security=restricted function from an attacker's point of view. However, this does not protect from client attacks, like the ones against Adobe's flash player, as client side technologies can all be hosted on the attacker's website. In this case, turning off JavaScript/VBScript and/or the vulnerable control/plugin/addon are the only current solutions. Conclusion: While we have spent a lot of time attempting to enumerate the issues, there will no doubt be a great deal of new issues related to this vulnerability. The scope of most CSRF fixes do not appear to appropriately cover the threat landscape either. Most importantly this will almost certainly require browser help to fix this issue, as the generic concept of clickjacking appears to be too dangerous and widespread to be left in the hands of webmasters alone for fixes. Thanks: Thanks to Microsoft's MSRC, Adobe PSIRT, Apple's PSIRT, Mozilla's security team and the various other security organizations for help in validating the vulnerabilities and working on fixes. Please check this page again as there is more information to follow as vendors patch undisclosed bugs.

Hom e

C onsulting

Pape rs

Ne ws

About

Bios

C ontact

Se cThe ory, LTD is 2006-2012. All rights re se rve d.

www.sectheory.com/clickjacking.htm

6/6