Still think allowing users to upload files to your server is OK?
There has been quite a bit of buzz surrounding the newest Flash attack. Please review this site for a quick write-up. I want to make it clear this attack vector is different than a remote vulnerability in Flash. This attack is focused on an individual uploading a flash file to a server and then having it execute when a user visits the site.
Adobe has a nice write-up out lining the issue and their initial response to the problem here. I really like the write-up and the quote of a core axiom of computer security: “If you allow a bad guy to upload programs to your web site, it’s not your web site anymore.” That is very true.
However, in the article they re-state that the issue at hand is the Same Origin Policy issue. Mike Bailey of Foreground Security neatly breaks down where the Adobe response fails to completely address the issue
The point he makes is Adobe draws similarities between Javascript and SWF files. He shows that this comparison has some very interesting limitations. First, simply uploading a .js file to a webserver does not mean the file can be executed. However, if someone were to upload a .swf file to the server it can be executed within the context of the server. Now… Here is where it gets interesting, if a user loads a .swf file to a server and changes the extension, it can still execute within the context of the server. Who thought this was a good idea?
His point is that the scenarios where .swf files can be executed is far more pervasive then the .js counterparts that Adobe discusses.
The reason this fascinates me is that it is outside the bounds of what penetration testers would normally look for in a web application. Because this attack vector is not a remote exploit, it does not get the buzz that it deserves. The point is that when we are testing we need to look for vulnerabilities and attacks that attackers would use. This attack vector is definitely in that category. Further, this is not something that is easily fixed with a patch.
There are two things we need to take from this. First, file upload attacks have to be in your arsenal. Second, from the defensive side, Adobe is right. As much as I would like disagree with the technical aspects of their response to this vulnerability, they are correct. If you design your web infrastructure to allow file uploads and for those uploads to be executed, there are going to be serious security ramifications. What would be the alternative? Flash could try fix their plugin to at least validate file extensions before executing, or possibly require the content-type headers in the HTML (not in the file) before executing the flash, thus bringing it more in line with the analogy with Javascript they discussed in their write-up.
Until they do (and I don’t expect this to happen any time soon) we will have a new vector to test for in our engagements.

John Strand will be teaching SANS Network Penetration Testing in
London from 11/30 to 12/6 2009, and SANS hacker techniques and Incident Response in New Orleans from 01/10/10 till 01/18/10.

About the author