Interview With XS-Snipers

Fri, 27 Jul 2007 14:59:24 GMT
by mario-heiderich

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

Q: How did you discover the potential of URI handler research?

Billy was eating a peanut butter and jelly sandwich and a big glob of peanut butter fell on the keyboard and typed res:// and pushed enter into his IE window. No, seriously, Rios discovered some interesting stuff with the res:// URI, shortly there after I discovered some articles around the ms-its:// URI and figured this may be an avenue of attack. I did some research on IANA registered URI's, then found a way to query the Windows registry to determine all registered URI's and the commands that are run when they are accessed by a browser (this was later turned into the DUH tool by Erik Cabetas. Shortly there after, I discovered the Trillian AIM stack overflow flaw and Rios discovered the Integer overflow in res:// (MS07-035) and we knew we were on to something hot. Around this time Rios and Thor discovered the FirefoxURL command injection and Rios and I got busy putting together a string of command injection attacks. We found one in Trillian exploitable thru the IE browser, the navigatorurl flaw exploitable thru IE, and the list goes on and on (see below).

Q: what testing methods did you use?

The primary point was the research around what URI's existed... we had some other methods, using regmon and filemon that we'll hopefully detail in full at BH Japan or another conference this year. Additionally, Rios's use of filemon to see what files were getting accessed was key to the successful exploitations around this issue.

Q: where do you see the greatest danger in the discovered issues?

The attack surface really. I mean, that's what XSS is all about... a persistent one, you post it in one place the attack hits everyone, but now, instead of stealing someone's cookies we're running arbitrary coammnds on their machine. Additionally, we keep saying this is just the tip of the iceberg. Right now everyone is focued on preventing these command injections, but the real flaws will be exposed in the functionality that the applications tied to these URIs expose.

Q: what's you disclosure ethics regarding issues with impact that high?

Constantly changing... we've had some difficulty with this. We've encountered several headaches when attempting to disclose directly to the Vendors including the recent PR war... additionally, we've encountered headaches when trying to disclose to vulnerability puchase programs.... which I won't get into at this time. Finally, when Rios released the MS07-035 we heard a lot of complaints from the community about us sitting on the vulnerability and not reporting it to people since it had been around so long. I think it's a lose, lose, lose situation at times.

Full disclosure allows for the fastest reponse time, keeping the exploitation window small. It allows corporations to take measures to protect themselves before the patch is released, especially when released in conjunction with temporary fixes such as noscript sigs, php ids sigs, and user controllable fixes (like modifying the registry in our case).

Q: what's next on the road map?

Attacking other browsers and other platforms... there's also a few methods of obfuscating these attacks that may be useful, and of course we have the aforementioned attacks against the functionality exposed by these URIs. Rios's presentation on anti-DNS pinning within the Java Virtual Machine (which will hopefully take place at BH Japan,etc.) scares me terribly. This dangling pointers issue at BH this year is causing a big stir.

Here is our discovered vulnerabilities in several URI's. The first portion is really the main one that is due to browsers not properly sanitizing data, the others result from the backing applications not properly sanitizing data or on the backing applications functionality.

Command Injection Flaws due to browsers not properly sanitizing data:

Overflow Conditions due to applications not properly sanitizing data:

Local Program Enumeration in IE7:

Local Program Enumeration in Firefox:

Functionality Abuse on Firefox:

Archived Comments

David KierznowskiDavid Kierznowski
Nice work there guys, simple, neat and clean.