How to prevent clickjacking attacks with security policy, not technology

By John Strand, Contributor | Jan 5, 2009

0 comments

Facebook

LinkedIn

Digg

Thumbnail: 

Many people believe that a malicious hacker's attempt to compromise their systems will be fairly obvious. But, unfortunately, today's stealthy attacks are more difficult to detect and won't be followed by a skull and crossbones graphic to inform users that they've been hacked.

We also tend to look at the Internet in terms of how we view real life. There are certain neighborhoods and places in our town that we just don't go to, for example, because there is a perceived risk of crime in the area. Many people believe that if they stay away from the shady areas of the Internet, they should be ok.

Unfortunately, attacks like clickjacking are changing this perception.

What is clickjacking?
First let's differentiate clickjacking from other Web-based attacks. Clickjacking is not cross-site scripting (XSS). In an XSS attack, malicious content is reflected back to a browser where it is then executed. It is not cross-site request forgery, either. With XSRF, a user views a page that contains a reference to a Web resource, like a picture hosted on another site. Instead of loading the picture, however, the browser is manipulated to execute a command, like a balance transfer.

Clickjacking is different; the attack is conducted by transparently overlaying the malicious function over something apparently benign. This type of misdirection is dangerous because the user interacts with a website that appears to be totally legitimate. Users who are clicking on a link or a button in a Flash game, for example, are, in fact, executing malicious code on the site. From the browser's perspective, the code execution is an authorized request from the user, so the browser carries out the order unimpeded.

The clickjacking approach can perform a lot of interesting, if not malicious, actions on a victim's browser. For example, it had been demonstrated that, via clickjacking, an attacker could trick a user to click on seemingly innocent buttons that, in actuality, could grant site access to the computer's webcam and microphone.

Because the action appears to be a request from the user, the browser will do pretty much whatever it is requested. An attacker could dump cached credentials to steal usernames and passwords, Web history, searches and potentially engage in malicious transactions.

But clickjacking is not limited simply to Web content. Web researchers Jeremiah Grossman and Robert 'RSnake' Hansen -- who, at Adobe Systems Inc.'s request, actually delayed their clickjacking presentation at the recent OWASP USA security conference in New York -- discovered this attack vector and also found a way to execute the same kind of attack in Flash files.

Clickjacking and the enterprise
How can enterprise environments protect against this attack? First, to defend against the Flash-based vector, set the 'Always Deny' option in the Global Privacy Settings of your Flash player. Doing so will prevent Flash from accessing resources like your video camera and your microphone. Adobe has released a patch so make sure to verify your patch level on non-Microsoft Applications.

It is a bit more difficult to protect the browser. Because of the many attack vectors, simply disabling JavaScript will not completely defend against clickjacking. I would strongly recommend that organizations tell their users to use the Firefox browser along with the NoScript plug-in, which provides preemptive script blocking and enables users to 'see' transparent or hidden windows. This new feature in NoScript, called ClearClick, reveals disguised, embedded elements and prevents their execution.

But even if users were able to see the potentially malicious content, would they know what is malicious and what is benign? User education is key here and, due to the nature of today's attacks, must be considered in different terms. Rather then simply trying to tell users not to click on links from strangers, or avoid non-approved binaries, security staffs need to look for ways to hold users accountable for what happens on their systems.

From a technical perspective, clickjacking is different from XSS or XSRF, but the attacks are all roughly similar when looked at from an enterprise risk-assessment perspective. When it comes to cross-site scripting, cross-site request forgery and clickjacking, the first action that leads to system compromise is likely the same: the user went to a site that was not work related.

Conclusion
In summary, the best recommendations for avoiding clickjacking attacks are not technical. If users are allowed to access the Internet as part of having a fun workplace, penalties should be established if a user's system gets compromised by visiting a non-work related site. An organization can decide what penalties will be enforced, but there must be some sort of consequence for a user's action if it leads to a compromise. If there are no penalties, employees and users may see no risk in going to sites that are not mission critical in order to perform their day-to-day job functions. Even if the risk is immense to the organization, the user will continue to partake in risky Web surfing if they are not directly impacted. There will never be an end of new attack vectors like clickjacking, cross-site scripting and cross-site request forgery so we need to keep our users educated and ready.

About the author:
John Strand currently is a Senior Security Researcher with his company Black Hills Information Security, and a consultant with Argotek, Inc for TS/SCI programs. He teaches the SANS 504 'Hacker Techniques, Exploits and Incident Handling,' 517, 'Cutting Edge Hacking Techniques,' and 560 'Network Penetration Testing' classes as a Certified SANS Instructor. Strand also answers your questions on information security threats.

0 comments

Facebook

LinkedIn

Digg