RIP browsers

If you have been sleeping during the last couple of days, here is an update for you: there was a discussion on Full-disclosure and Bugtraq about a very peculiar vulnerability in Internet Explorer and Mozilla Firefox which can be used by attackers to trick their victims into exposing sensitive files.

It was Michal Zalewski who brought this subject back on the table. The vulnerability he described is not new. In fact, it is a variation of an issues discovered back in 2000. The peculiar thing about it is that it was reported to Mozilla’s Bugzilla back then and still, none has fixed it.

If you read about what Michal’s exploit does, you can easily get lost into the complex inner logic, so I will try to explain the issue as clearly as I can and provide you with some examples of how it can be used in real attacks.

The only component in the DOM (Document Object Model) that allows us to send locally selected files to a remote location is the file input box, usually declared as <input type="file"/>. This is not a standard input field because it has a browse button that is attached at the end and also because, once inside a multipart/form-data form, it can send files. Because of these characteristics, you cannot use JavaScript to set its value to a file of your desire. If that was possible, everybody would be able to steal and list your file system remotely.

However, by using a clever focus diversion trick, attackers can make certain characters, that the victim types, to leak inside the input field. They can achieve that by using a filter that allows and disallows characters based on their order in the file path string that is wanted to be retrieved. Indeed, it sounds very complicated.

In simple words, when the user types characters inside some text field, they are actually typing them inside a file input box, which filters out the unnecessary characters in order to compose the desired string. Everything else, is totally emulated, so the user thinks they are typing in the right place, although as we already mentioned, this is not the case. The following text translates to /etc/shadow, which can be used to steal that particular file:

Bob! Check this out http://www.example.com. this is very cool: http://www.someserver.com. hei man, do you still need that wonderful CD I gave you long time ago?

You probably think that I am mad! Now, have a look at the following text, which shows all key characters that are required to build the file string.

Bob! Check this out http:[/]/www.[e]xample.com. [t]his is very [c]ool: http:[/]/www.[s]omeserver.com. [h]ei m[a]n, [do] you still need that [w]onderful CD I gave you long time ago?

Black magic! The filter removes the parts that are not required and only the characters that are needed are passed into the input field.

Although quite complicated, this attack is very real and you should take it seriously. When I saw Michal’s post on Full-disclosure, I knew what he was talking about because I used to play with earlier variations of this issue in the past. If the attacker places the malicious JavaScript logic on a critical place where users are heavily using the keyboard, the chances of composing the desired string are quite high. Think about blogs, wikies, forums, etc. This issue can be shipped as part of an AJAX worm which propagates on the top of MySpace, for example, and compromises the exploited users’ System registry. The registry, in Windows environments, contains sensitive information that can be used to compromise the victim’s identity: credit card numbers, VPN connections, passwords, you name it.

In some situations the user doesn’t need to type text at all. They can be tricked in a clever way. For example, the following sequence of characters composes the /etc/shadow string: b/etlc/shradow

It is not obvious that this 14 character long string corresponds to the 11 character long /etc/shadow path. Still, the question is how the attacker can force the victim to type these characters inside the page. Well, attackers need to be creative in this case. Check this two examples:

A screen is presented to you that asks you to build your on-line Artificial Intelligence soul, but first you have to train it by typing the following characters inside the page: b/etlc/shradow

You visit a private page that is restricted by a CAPTCHA. You type the letters b/etlc/ but you receive an error which tells you that your input was incorrect. Now you need to repeat the task and type the following sequence of characters: shradow.

Quite bad! My advice to you is to be careful. If you are using MySpace turn off JavaScript if possible. Don’t use your keyboard on dodgy websites. Use your mouse, at least it is safe for now.

I am very interested to see how Adobe Apollo is handling this issue. We have to wait till the first beta release. I cannot wait. BTW, during the discusion on Full-disclosure, I found an interesting bug that attackers can use to disable the address bar in Firefox and Opera browsers. This can be used together with the focus diversion trick to build more advance attack vectors. Check it out here.