Domonstration on Clickjacking – “Beware!!”

Please be careful when clicking on unknown links on sites and most of all Facebook.

This is what is now possible to get access to say your camera..and is is so easy you would not know what you clicked on

You Have Been Warned!!

Many people believe that a malicious hacker’s attempt to compromise their systems will be fairly obvious. But, unfortunately, today’s stealthy Web browser 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

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.

Facebook Clickjacking Example

If you’re still a little confused about what clickjacking is, then I suggest watching the following YouTube video.

This video shows how Narkolayev Shlomi made a click jack attack that added an application to his Facebook account. It’s a little dry and there isn’t any sound. Stick with the video to the end, though. You might be surprised to see what secrets lie in wait.

Shlomi strips away all pretense of subterfuge in this video to show users exactly how they fall victim to clickjacking attacks. As you will see in the video, Shlomi has created a web page that identifies itself as a clickjack demo. He then goes to his Facebook account to show the audience what applications he has used recently.

When he clicks “start demo” on the click jack page, the audience quickly sees that a new application has appeared in Shlomi’s Facebook account.

What you have just witnessed is a basic clickjack attack. It doesn’t do any harm, but it could just as easily be designed to open an application that captures personal information.

Shlomi draws back the curtain at the end of the video to show exactly how the clickjack attack works. The audience now sees that there is another screen hidden on top of the clickjack demo page. Not surprisingly, the hidden screen is a Facebook page asking permission to install an application.

Shlomi has shown us this to make everyone aware of the potential dangers that clickjacking poses. Unfortunately, what he reveals is that the average internet users might not be able to protect himself against these attacks. Even popular browsers and web sites have had a hard time creating security measures that can stop click jacking in its tracks.

This example could easily be made to trick users into opening applications on Facebook. Instead of a page that proclaims its clickjacking intention, Shlomi could have easily made one that showed pictures of LOL cats or something. The attacks become most effective when they convince you to lower your guard.

–

A great website that explains it all

http://clickjackingjack.wordpress.com/