Just recently I’ve tested a number of web applications that made heavy use of Adobe Flash. Considering I didn’t find a whole lot when I was searching I thought I’d document my current workflow.

To be honest I’ve never gone too deep into hacking up SWF files. So, after finding a few bugs in the non-flash areas I decided to invest a bit of time in disassembling and reassembling SWF files.

Most web app folk are at least aware of the flare and flasm tools, the go-to tools featured in the 1st Ed. of Web Application Hacker’s Handbook. These were the tools I knew existed and I attempted to apply them. Unfortunately in my situation these were near useless. Apparently flare and flasm are dead projects and have no roadmap for supporting ActionScript 3. A quick look over at the OWASP Flash Security Project got me in touch with RABCDasm. There are more than a couple disassemblers, but tools supporting reassembly appear limited. This suite did pretty much everything I needed.

I also like using HP’s SWFScan.  Not really for the static analysis (your mileage will vary), but for the neatness and ease of a friendly AS3 format.

So, here it is:

1. Acquire SWF file
2. Run SWFScan on the file
3. Follow the RABCDasm usage to the point that you’ve disassembled the .abc files
4. grep -i -r these directories for keywords that you’ve located using the more readable AS3 in SWFScan
5. Make appropriate changes
6. Follow the RABCDasm usage for reassembly
7. Start up a python -m SimpleHTTPServer 80 in the reassembled SWF directory
8. In Burp, make a proxy replace rule to replace the normal content with your new file
9. In Burp, make a proxy replace rule to replace the AllowScriptAccess parameter from “sameDomain” to “always”

Anyway, given this setup it’s not entirely difficult to at least test and attempt to attack things like client-side input validation and controls. That said, learning some ABC is in order as I’m just flapping my fledgling flash flippers.

Comments and suggestions welcome.

Code, Exploitation actionscript, adobe, flash, web applications

Recently I’ve decided to pull my ‘pdf_plus_js.pl‘ perl script out of retirement and repurpose it for fuzzing javascript functions in PDFs.  With some very minor tweaks we can loop through arrays of fuzz data and multipliers to quickly generate decent samples of PDFs to test with.

This started as a pretty nasty hack.  I’m not above saying so.  Hold on to your peanuts though, it gets nastier.

Read more…

Code 0day, adobe, javascript

Walk with me.  Let me rap unto you a little story about how an AV detection might go.  So, your AV makes a good detection on a suspect file.  Unbelievable already right?  Say it does, but it’s using a heuristics engine and not it’s typical signature definitions.

For Symantec these heuristics are Bloodhound and files that are flagged usually get some name such as ‘Bloodhound.exploit.somenumber’.

So, is this it?  Leave it and move on to the next thing that will burn up the day?  It doesn’t have to be. Let’s dig deeper. Read more…

Anti-malware adobe, javascript, malware, pdf