I've been motivated by the recent posts by Billy "BK" Rios and Thor on some of the recent URI issues that are being discovered. In Rios's posting, and on his site he touches on some of the research that he, I, and Raghav "The Pope" Dube have been doing. Thor took some of the research we were doing to the next step with the FirefoxURL flaw, and in one of the interviews (http://www.adtmag.com/article.aspx?id=20963) he recently had about the issue he mentions that aim://, irc://, and others may have flaws as well. This is in fact the case.

Here's the paper (http://www.xs-sniper.com/nmcfeters/URI_Use_and_Abuse.pdf) on URI Pwnage that I had submitted to DEFCON it contains the XSS attack that will land you control of SEH and pointer to next SE Handler from the Trillian flaw as well as some other goodies.

Hope to see you all for me and Rios's talk on "Biting The Hand that Feeds You" at DEFCON this year. We'll do a quick preview of some of the new things we've discovered with URIs which we hope to present at BH Japan. It should be... entertaining.

-Nate

very nice. should be interesting to see what comes of all this. shoutz to tha pope and BK


Rob

nmcfeters Wrote:
-------------------------------------------------------
> aim://, irc://, and others may have flaws as well.
> This is in fact the case.
> DEFCON it contains the XSS attack that will land
> you control of SEH and pointer to next SE Handler
> from the Trillian flaw as well as some other

cross application scripting is a great name for this sort of thing. we're going to see more and more of this in the future.

when I watched the video on writing xss w0rms on milw0rm
[milw0rm.com]
i came up with some ideas that involve cross application scripting in a very similar way that you just spoke about.

in the video, the author shows how to exploit xss in meebo to control the functionality that meebo has access to. i thought that it would be interesting to send shellcode over meebo's im infrastructure to the fat im clients. the worm could enumerate all of the people on the buddylists and send an xss that contains the shellcode that would allow loading of a syscall proxy or rootkit, etc into the vulnerable fat im clients. thus, cross application scripting - but with an xss worm twist.

as air, silverlight, gears, et al roll out - we're going to see even more cross application scripting type attack patterns.

i'll have to read through all your work and let you know what i think.

I've posted the samples from the paper on xs-sniper for those who want to see the real deal...

Cross App Scripting (Trillian/aim.dll overflow) --> [www.xs-sniper.com]

IE Local Software Enum --> [www.xs-sniper.com]

FireFox Data URI --> [www.xs-sniper.com]

BK



Edited 1 time(s). Last edit at 07/12/2007 01:04AM by BK.

Most of that paper is really cool, and thanks heaps for posting it here, but I don't see your point when you're talking about the Firefox data: URI scheme.

I really don't see why an attacker would bother using the data: URI scheme, because all it does is provide a URI which is most obviously not google, but the user can't tell what it is, but this can be just as easily achieved by IP obfuscation.

{EDIT]: Ok, after re-reading that section of the paper, I saw your point, that phishers could send data: links in emails, well, its not gonna happen, because the hackers got there first, since (last I checked) you can XSS users via the data: URI, and so it needs to be filtered anyway.



Edited 1 time(s). Last edit at 07/12/2007 12:55AM by kuza55.

I agree, I stole it a bit from Rios with his Cross Browser Scripting title. I think he started a trend. I'd not be suprised if this aim:// URI also had potential for command injection.

Nice paper, however you didnt include DUH (DUMP URL HANDLERS) on the appendix section (as the paper claimed).

Yep, took it out on purpose for now. Rios and I want to talk to Erik Cabetas and Shawn Sherman who helped us with it first. We may just go ahead and release it with our presentation at DEFCON or something too. We'll figure something out and get it out there, so I guess just check this thread for updates.

data:'s a standard and supported in pretty much everything but IE - [en.wikipedia.org]

According to that even KDE's file browser supports it, which is interesting - I wonder what context they're run in and whether an OS browser run data URI is capable of making contact with content outside of the OS' context.

The underlying issue has been around for quite some time. There's buffer overflows available for AOL Instant Messenger using the AIM protocol through different means (direct link, XSS, CSRF) that have been around since 2000. I do like where this is going however.


Awesome AnDrEw - That's The Sound Of Your Brain Crackin'
[www.awesomeandrew.net]

Well, the underlying issue here really has nothing to do with Trillian at all and everything to do with the fact that all of these URI's exist.

Take a look at post number two for trillian and you'll see what I mean. There's all kinds of flaws going on for these things. All leverageable thru XSS.

Yeah, I wasn't specifically referring to Trillian only that various protocols used by applications can be exploited through XSS.


Awesome AnDrEw - That's The Sound Of Your Brain Crackin'
[www.awesomeandrew.net]