Thursday 9 October 2008

ClickJacking, the new kid in town

There is a lot of buzz about this at the moment. I thought that there would be after it was requested that it not be mentioned in the OWASP meetings So, what is it?

Well, to start with, let us say what it isn’t because that is important.

It is not:



1. A single exploit. It is a class of exploit rather than a specific example.

2. It is not a really a remote code execution sort of vulnerability so it doesn’t allow an attacker to take complete control of your system. It is more like a cross side scripting attack against the browser if such a thing were possible.

3. It is not a code defect in any particular browser and it is not a bug in Macromedia Flash. The first proof of concept just used Flash.

4. It is not browser or OS specific.


What it is:


1. A browser based exploit. If you are not viewing HTML, it can’t have an effect.

2. A way of getting a mouse click on a web page to mean something other than what the user means it to mean.*

3. A way of getting the browser to do what it could already do had the user asked for it

So, the exploit hijacks a click hence the name ClickJack. By why did I put a * by the side of the entry? Well, that is because the name is a little misleading. No-one else seems to have mentioned that you should be able hijack keystrokes that have the same effect as mouse clicks. I am willing to bet that you have accidently hit on this functionality a dozen times. In a text box that doesn’t accept multi-line, hitting the enter key will normally submit the form – I have cursed a hundred times when a logon was submitted without the password because I typed Enter when I meant Tab. Backspace takes you back one page. Tab and Shift Tab change the focus and that can fire an onFocus event. Accordingly, I don’t see that this is limited to mouse clicks.

What could be done with this class of exploit?



Well, the proof of concept was rather clever. It fooled the user into turning on their microphone and web camera. There has been malware that did this and then relayed the image before and it was much loved by paedophiles. However, this was just a proof of concept and didn’t do anything malicious.
Essentially, a malicious page could persuade the user (through social engineering) to take an action such as clicking a button that could be converted into a click somewhere else on a page. In the case of the proof of concept, it was a dialog provided by flash to enable or disable the webcam and microphone features on Flash. However, it could be used to submit a form or open a new link – basically, whatever you could trigger with a click. It hijacks the click for its own purpose.

So, what does this add to the mix? Well, not as much as you might think. Pages that advertise scareware tend to be one big bitmap including the “close” button and any action takes you to the next stage in the process of installing the “potentially unwanted software”. Essentially, when you are viewing a malicious page, any interaction with it was likely to do things that you didn’t want. So, Clickjacking is another way that this can be done.

How does it work in practice?



That hasn’t been made public but it is fairly obvious how you could do it. If you put the object that you want clicked under a graphic that the user will click on and then make the graphic invisible for part of the time, the graphic will seem to flicker – and repeated mouse clicks will sometimes hit the graphic and will sometimes hit what is underneath it. That sometimes happens in regular form based programs when controls are hidden and shown to customise the form. The required DHTML is trivial. Maybe you could have a simple game where the user has to click repeatedly on a butterfly as it flits around the screen. That would do the job nicely. The best use for this would probably be to hack a bank site or a stock trading site to add a malicious iFrame that covered the real content of the page. Of course, if you can do that, you have probably already won.

Mitigation



Well, the old rule applies. Do not interact with sites that are malicious. Of course, the malicious functionality could be in a banner ad or something like that and accordingly, clicking on banner ads may be unwise. I never do it anyhow which must come as a disappointment to those that pay for these things.

Running the browser with fewer rights is always a good idea. On Vista, Server 2003 and Server 2008, this is the default state. On Linux, you can spawn the browser with lower rights manually. This doesn’t mean that you won’t get exploited. It just means that the exploit will be able to do less.

Disabling DHTML in emails (again, default post server 2003) is also helpful.

Fixing the problem



Now, that is a tricky one. A lot of people want this fixed but it isn’t a security flaw in the classic sense. There is no buffer overrun. The browser is doing what it was asked to do. If you fool people into clicking the wrong thing then that isn’t really anything that the browser can fix. I think that you would need to disable at least the following things:

* Making controls visible or invisible under script control or in response to events

* Allowing controls to move under script control or in response to events

* Allowing irregular shapes

Doing that would break a lot of critical sites.

Hope that this information was of use to you.

Signing off,

Mark Long, Digital Looking Glass Ltd.

No comments: