A page to show up #1 on Google when searching for "Jeremiah" (Currently #4). Only the prophet and TV show left! I have the edge, TV show is cancelled and the prophet isn't generating any new content.

The prophet, TV show, and that pesky Owyang guy going down!A page to show up #1 on Google when searching for "Jeremiah Grossman", and it FINALLY has!

Saturday, January 05, 2008

New Flash XSS technique (thousands of websites at risk)

This week I spent a good amount of time studying the recent attack technique disclosed about XSS issues in common Shockwave Flash Files. At first I thought, “eh, looks cool, but probably just some theoretical edge case”. Then in working with white paper author Rich Cannings I came to understand that the details are more complex than I originally gave credit. Apparently the scope of the problem is easy to underestimate with potentially hundreds of thousands of websites at risk (right, as if we needed more XSS to deal with). The other thing is that reasonably workable fixes are going to be a long time coming.

In many ways the issue is similar to that of Adobe’s Universal XSS problem from last year. At its simplest, this issue describes that vulnerable Flash files can be used to XSS the hosting domain. The URL would look something like this:

The URL looks a little different than the XSS exploits we’re used to, but still straight forward enough to understand. So I went to test on www.whitehatsec.com since we use some Flash and try to get some of the paper’s PoC working, much of it researched by Flash hacking extraordinaire Stefano Di Paola. I wasn’t having any luck and couldn’t tell if I was doing something wrong or we weren’t vulnerable, so I asked Rich for some assistance. Turn out the latter was true, but I also learned that just because a website is hosting a Flash file doesn’t automatically mean its XSS’able or XSS’able in the same way as another.

2) Commonly used Flash files design patterns also leave room for the same XSS problem. If you read the white paper, Flash developers need to perform the same input validation as web application developers.

Solutions where things get tricky…

- Patch the Flash authoring tools - a half dozen tool vendors have been notified with fixes available. The challenge is this requires all Flash developers not only patch, but also regenerate their files and update them on the server. Also website owner often to do not develop their own Flash and rely upon third-party marketing firms who must be contacted. As a result, this process will take significantly longer.

- Users update their Flash player – Based on the nature of the issue, I’m not certain of how much benefit to this there is, but might as well patch anyway if there is one available.

- Disable or block Flash content – I think most people reading this probably already do some form of Flash blocking, but for everyone else, there are simply not going to.

- Remove Flash files from the Web – Sure this could work in some cases, in others it’s easier said than done. Some websites are completely reliant upon Flash and removal is out of the question. Others use Flash for simply advertising purposes, those are going to be difficult to just arbitrarily delete as well.

- Move Flash files to a secondary domain – just as is recommended with all third-party / user generated / untrusted content. This solution has promise as it sets up some domain barriers in the event a vulnerable Flash file shows up linked from your website.

Vulnerability identification is another area of significant interest…

Because this issue is NOT a universal XSS as it is the case of the Adobe PDF bug, issues are going to be harder to track down. We’re going to have to figure out ways decompile/reverse engineer Flash files to determine what authoring tool was used and update our vulnerability scanners so that Flash files can be tested in much the same ways as a web application. This is going to be interesting. Welcome to 2008 everyone, Web 2.0 hacking abound.

Probably not (obfuscation techniques not withstanding) in the long term, short term maybe. All the different Flash authoring tools have different ways (parameter names) to get JavaScript to execute. So there probably isn't going to be an exhaustive list to black list against. For now you may be able to get some risk reduction by request blocking until the Flash files can be inspected/fixed.

Ok, so that leaves with us Flash off - while not being able to view Flash safely until a fix is provided.

This isn't really acceptable. Fortunately, I've come up with a reasonable solution. I run NoScript under multiple Firefox profiles. On one of them, I can run Flash (after every Flash file, I close/exit the browser and start a new process), but I don't login to anything (including YouTube) in that window, so that my cookies are clean. I also check using Oblivion what Flash LSO's are stored locally, and use Sol Editor to find out what's inside them. I could disassemble or decompile every Flash I download, but this is a bit excessive.

Under Internet Explorer, I use TurnFlash to "turn Flash off", and there is both a CLI version and a GUI version available. This tends to speed things up a bit as well. I'm also using the Netcraft Toolbar under IE, which claims to "Block Cross-Site Scripting (XSS) Attacks", although I'd be willing to bet it's nowhere as near as complete as NoScript.

Sometimes I'm not even sure that NoScript is safe enough for browsing. I would say it's fairly complete, but every once in awhile someone is able to sneak an XSS through. Or a Jar file URI attack is found. NoScript usually adds protections for these very quickly; I am extremely impressed by this. However, like I said -- it doesn't make me all warm and fuzzy inside like using a browser that doesn't have an implementation of Javascript at all.

Worse, it appears that Javascript is no longer the only problem (and I'm not talking about IFRAME, which NoScript does protect against). HTML/CSS clobbering (like Javascript clobbering) is injectable anywhere where user-submitted HTML/CSS is allowed, and it doesn't have to launch Javascript in order to change the look and feel of a website (in order to promote a phishing attack).