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:

http://example/ FLVPlayer_Progressive.swf?skinName=asfunction:getURL,javascript:alert(1)//

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.

Vulnerable Flash files are primarily generated in one of two ways:

1) A Flash authoring tool inserts some generic ActionScript that’ll execute arbitrary JavaScript.

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.