With the ever-growing threats of malicious softwares, the advent of clickjacking is a cause of worry for every net users. Having raised the alarm for this threat, it is high time that we know the threats posed by this malware. In this article, we will study the working and also the exploits of clickjacking affecting all major desktop browsers.
If you thought your computer is attack-proof merely because you had a fully-updated and licenced antivirus software, then you may have to re-think. A browser vulnerability, clickjacking, has come to light and has caused enough anxiety among the security researchers. In fact UI redressing or clickjacking has gotten a lot of attention lately, and for a good reason because it's quite malicious.
So while you might think you are clicking on your bank funds transfer link, or saving a favourite URL (Uniform Resource Locator) link at Digg, or some innocuous Facebook application, the reality could be entirely different, and dark. Even though initially, when clickjacking came to light and had caused enough anxiety among the security researchers, the worrying news is that none of the common users are aware of the technicalities of the risks of this menace.
The Term
Clickjacking is a malicious technique of tricking web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. A vulnerability across a variety of browsers and platforms, a clickjacking takes the form of embedded code or script that can execute without the user's knowledge, such as clicking on a button that appears to perform another function.
Clickjacking, a term coined by Jeremiah Grossman and Robert Hansen in 2008 can be understood as an instance of the "confused deputy problem". A confused deputy is a computer program that is innocently fooled by some other party into misusing its authority. It is a specific type of privilege escalation. In information security, the confused deputy problem is often cited as an example of why capability-based security is important.
In general terms, a simple countermeasure to clickjacking is to use framekiller JavaScript to prevent the site from being included in a frame.
Cross Site Request Forgeries
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.
The Attack
As a web user, you may have the ability to initiate privileged actions that others cannot. For example, you can delete all the email from your web-mail account, or liquidate your stock portfolio, or start recording video from your webcam. Normally, you initiate these actions by clicking on buttons in web pages. A clickjacking attack can be used to direct seemingly benign mouse clicks to these privileged buttons. For example, you may think you're playing a game, when you're actually starting a webcam recording. Using only CSS (Cross Site Scripting) and HTML (HyperText Markup Language), an attacker can create a transparent IFRAME of a victim web page that contains privileged buttons. Underneath this transparent IFRAME, the attacker puts content, like a game, that entices the user to click. Although the user only sees the game, the mouse clicks are delivered to the transparent buttons, since they are on top of the game.
Clickjacking, also known as UI Redressing, is possible not because of a software bug, but because seemingly harmless features of web pages can perform unexpected actions.
A clickjacked page tricks a user into performing undesired actions by clicking on a concealed link. On a clickjacked page, the attackers show a set of dummy buttons, then load another page over it in a transparent layer. The users think that they are clicking the visible buttons, while they are actually performing actions on the hidden page. The hidden page may be an authentic page, and therefore the attackers can trick users into performing actions which the users never intended to do and there is no way of tracing such actions later, as the user was genuinely authenticated on the other page.
Example 1
Here is an graphical example of a clickjacking attack:
Figure - 1 : Example of a Clickjacking Attack
In this example, an attacker carries the clickjacking attack using a technique called IFrame overlays. In this technique, the malicious Web page includes code that generates the fake UI and an IFrame that points to an email application at a different domain. When the two are combined the top-level page covers portions of the IFrame in order expose only the “Yes” button and the user can be easily tricked into deleting all messages in his inbox.
Example 2
With reference to a clickjacking attack, for example, a user might play a game in which they have to click on some buttons, but another authentic page like a web mail site from a popular service is loaded in a hidden iframe on top of the game. The iframe will load only if the user has saved the password for its respective site. The buttons in the game are placed such that their positions coincide exactly with the select all mail button and then the delete mail button. The consequence is that the user unknowingly deleted all the mail in their folder while playing a simple game. Other known exploits have been tricking users to enable their webcam and microphone through flash (which has since been corrected by Adobe), tricking users to make their social networking profile information public, making users follow someone on Twitter, etc.
In simple words, clickjacking is an attack where a user clicks on a button in a browser, thinking the button will perform a specific function, such submitting a news story to digg.com, but instead an attacker hijacks the button to use it for another purpose.
Clickjacking Techniques
Having familarised with the clickjacking attacks, let us briefly study its techniques. Main techniques that are available for attackers to carry clickjacking attacks are through:
Javascript: By using Javascript this attack becomes easier to deploy. This is since the original UI can be further manipulated in ways that are not possible when using only HTML. For example, the attacker can move the embedded Web page within respect to the browser window so that a specific button will be always under the user’s mouse cursor.
Flash: The clickjacking vulnerability in Adobe Flash Player has even further implications since attackers can gain access to attached hardware such as Web cameras and microphones.
The clickjacking vulnerability in Adobe Flash Player has even further implications since attackers can gain access to attached hardware such as Web cameras and microphones.
The main risk imposed by the clickjacking attack is the ability to bypass nonce based CSRF defenses, which is considered the most robust protection against CSRF attacks. This defense involves adding a nonce to each transaction. The value of the nonce attached to the request is validated against the value given for a specific user session. Thus, an attacker cannot embed a URL representing a valid transaction in the attacker’s controlled page. However, in the clickjacking attack, the user interacts directly with the target Web page so all transactions include a valid nonce and the attack is left undetected.
Figure - 2 : Clickjacking Attack on Adobe Flash Player
Click Fraud
Click fraud is another great example of where clickjacking can be extremely useful. While traditional click fraud requires a large group of disparate (Internet Protocol) 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.
Risks and Challenges
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 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 there 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.
Attack Mitigation through Code
Since the vulnerability that allows clickjacking attacks resides in client software and not in Web applications, there is no complete solution except of presenting fixes to the vulnerable platforms. One countermeasure that can be applied in some cases is preventing a Web page from being framed. This is done by embedding frame busting code in the Web page, for example:
if (top != self)
{
Present error to user
}
This code will generate an alert when the Web page is embedded into a frame. However, this solution has the obvious disadvantage for Web sites that facilitate frames.
Although the clickjacking attack can overcome most CSRF protections, SecureSphere’s integrated CSRF protection is not compromised. CSRF protection in SecureSphere is based on the dynamic profiling mechanism. This mechanism helps SecureSphere detect and block authenticated requests to internal resources from suspicious domains.
Prevention
Mozilla Firefox has no native protection against Clickjacking. Protection against clickjacking can be added by installing the NoScript add-on: its ClearClick feature, released on 8 October 2008, prevents users from clicking on invisible or "redressed" page elements of embedded documents or applets, defeating all the types of Clickjacking (i.e. frame-based and plugin-based).
Web site owners can protect their users against UI Redressing (frame based Clickjacking) on the server side by including a Framekiller JavaScript snippet in those pages they do not want to be included inside frames from different sources.
Such JavaScript-based protection, unfortunately, is not always reliable. This is especially true on Internet Explorer, where this kind of countermeasure can be circumvented "by design" by including the targeted page inside an <IFRAME SECURITY=restricted> element.
On 26 January 2009 Microsoft released RC1 of Internet Explorer 8, which includes a new partial ClickJacking prevention option. Web site developers will be able to add a tag in a page header to help detect and prevent frame-based UI Redressing. IE 8, according to Microsoft, “will detect sites that insert the tag and give users a new error screen indicating that the content host has chosen not to allow their content to be framed, while giving users the option to open the content in a new window.”. According to NoScript's developer Giorgio Maone, however, this feature can be regarded as a work-around for Framekillers being broken on IE and, "if a web site owner is skilled and careful enough to implement" this countermeasure, "he will surely deploy the simple and understood JavaScript frame busting one-liner too, and every browser is equally protected".
Microsoft's suggested solution, which has since also been implemented in Apple's Safari web browser, is to check for a new HTTP header, X-FRAME-OPTIONS. This header can have two values, DENY and SAMEORIGIN, which will block any framing or framing by external sites, respectively.
Both Framekillers and IE8's mitigation approach, however, require web developers to protect vulnerable pages by modifying their content or the way they are served, although, even on "protected" pages, they cannot prevent plugin-based Clickjacking variants since they don't need frames. The NoScript add-on for Firefox remains the only free product providing automatic client-side protection, with no need for awareness and cooperation from the web site authors.
Future Concerns
There are a wide variety of websites that use one time tokens (nonces) to protect themselves from CSRF (Cross Site Request Forgeries) attacks that would be vulnerable to the clickjacking 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.
—By:R. Manoj. The author is an Assistant Editor at Fanatic Media, Bangalore. He is also an Independent Researcher, specializing in Software Security. He has an active interest in designing security algorithms for securing softwares. He can reached at infosecurity@fanaticmedia.com |
