U R Insecure - How URI Exploits Are Changing The Webappsec Landscape

Fri, 27 Jul 2007 14:59:53 GMT

by mario-heiderich

This article is about the recent activities and research that have been undertaken around the area of uri handler implementations in modern browsers. It is also about the tremendous security problems that were discovered as a result of that. And it is also about the ways application developers can protect their users from the raising threat.

Once upon a time...

Browsers have URI handling features for quite some time now. They are pretty neat and enable the developer to pass application commands through the browsers sandbox to tools and software installed on the users' computer. It creates a bridge between the Internet and our local application repository and enables handy things like skypeing a person directly from a website, sending torrent links directly to the registered application and much more. Among the URI handlers you can find real oldies like gopher, telnet and news as well as the cool things like magnet, joost and itpc. Internet Explorer 7 utilizes the res handler to locate resource - for example the blue info icon on the 404 pages. Last but not least, we all know the data URI which allows us to use an arbitrary data stream - in base64 or an any variant of UTF - parametrize it with a MIME type and pump it directly to the browser via the address bar.

Then people found out how to misuse those URI handlers - crafted exploits and phishing kits - there was a boost of small file scanners and cleverly crafted buffer overflows popping out everywhere. But the last couple of weeks were quite extraordinary. Security researches, including Billy Rios, Nate McFeters and Thor Larholm, found out various ways to exploit the URI handlers, unleashing the possibilities of danger. They discovered that many browser implementations don't properly sanitize the data passed via the URIs. With quotes and null bytes it's possible to circumvent the browsers' ability to handle the incoming data and slip out of the sandbox. The results? - exploits which actually enable an attacker to access the local file system of the victim.

It's just an exploit, mom

The vectors they figured out are pretty manifold - and when watching the list of supported URI handlers for Firefox alone, one might understand pretty quickly that there are almost no limits when exploiting these issues. Bellow you can find a few examples of recently disclosed vulnerabilities which are all able to trigger code execution on the victims system, for as long as the victim is using a win32 based operating system:

firefoxurl:test|"%20-new-window%20javascript:alert('Cross%2520Browser%2520Scripting!');"

snews:%00%00../../../../../../../../windows/regedit.exe " - "../random/file/to/create/some/fun" %00.bat

res://c:\\program%20files\\adobe\\acrobat%207.0\\acrobat\\acrobat.dll/#2/#210

navigatorurl:test"%20-chrome%20"javascript:C=Components.classes;I=Components.interfaces;file=C['@mozilla.org/file/local;1'].createInstance(I.nsILocalFile);file.initWithPath('C:'+String.fromCharCode(92)+String.fromCharCode(92)+'Windows'+String.fromCharCode(92)+String.fromCharCode(92)+'System32'+String.fromCharCode(92)+String.fromCharCode(92)+'cmd.exe');process=C['@mozilla.org/process/util;1'].createInstance(I.nsIProcess);process.init(file);process.run(true%252c{}%252c0);alert(process)

As you can see it's not only possible to enumerate the clients file system or to just execute some harmless programs on the victims' machine - it's also possible to parametrize the calls. This is dangerous. Moreover, the malicious event will occur remotely as soon as the user clicks a malicious link (firing the link via JavaScript is also possible). But wait a second. Let's make some connections. There was this XSS thing - injecting malicious content into other peoples' websites. The XSS thing where lot's of people said that it's not really an issue. The thing that even people like David Heinemeier Hansson ask me why there's a problem if one is able to create an alert in an important part of one of his applications. Problem? I think so!

Q&A from the researchers

Here's some Q&A from some of the researchers of the URI exploit issues I recently had a phone conference with - thanks for the time and the quality talk, Billy and Nate.

Please don't make it happen!

Tests have shown that these exploits work perfectly well in combination with iframes and javascript redirections - it would have been a miracle if not.

So anyone who is able to use these exploits, make them do the stuff he/she wants them to do and knows a website with persistent XSS on it, is able to create a really dangerous threat to all the attacked websites' visitors and beyond.

We're talking about remoting the clients, shutting down computers, networks, formatting disks - yes, formatting the disk and so on. What about XSS worms? With the available possibilities it is possible to create XSS worms that really wreck up the clients' system - after stealing cookies and infecting every account. And do not forget that there are a bunch of ways to obfuscate the payload to make it even harder for IDS systems and filters to detect and sanitize those attacks.

So - how can we protect ourselves?

Pretty difficult to find an answer on this question without leaving someone out. Users have only a few options to chose from. First of all, it is recommended that you always use the most current version of your favorite web browser. Do not ignore patch updates - never - even if it hurts to use automatic updates. Furthermore Giorgio Maone is optimizing his Firefox extension NoScript to detect and block those kinds of attack - this tool has been and is definitely worth to be tried out. I can only repeat what thousands of other said before me - don't follow untrusted links, don't visit untrusted websites, don't open un-demanded attachments and you better think twice before clicking on a dialog to move it away, especially when it's your browser telling you to let it update itself.

But what's even more important - what can developers do to protect the users on their websites? I must say that you shouldn't allow XSS under any circumstance. Filter your input, filter your output and don't ever allow the user to break the markup. Second - be damn careful when it comes to allowing the user to post links. Make sure that the URLs can only be entered in correct format. At least make sure the URL is prefixed with http(s):// - this is weak protection, I know, but it is better then no protection at all. Alternatively you can follow any user supplied link including redirects and check for availability and the sources after the last redirect. Not a perfect protection - I know - but a little bit better. Another tear of security can be created with using the PHPIDS - I don't want to self promote but the system is capable of detecting the exploits with pretty high impact and our team is closely working together with Billy and Nate so we are able to keep the detection rules pretty up to date to maximize the protection.

Conclusion

Without wanting to peddle FUD I hope that you understand that these issues are really dangerous. Most of the stuff, except the excellent research of Billy, Nate and Thor, is not really new. It's important to know what is possible and it is important to see that attack techniques like CSRF and XSS gain tremendous potential damage when mixed with these URI exploits. What do you think?