HP's Free Adobe Flash Vulnerability Scanner
Catalyst writes "SWFScan is a free Flash security tool (download here), released by HP Software, which decompiles all versions of Flash and scans them for over 60 security vulnerabilities. The scan detects things like XSS, SQL inside of the Flash app, hard-coded authentication credentials, weak encryption, insecure function calls, cross-domain privilege escalation, and violations of Adobe's security recommendations. There is also this video explaining a real, and amusing, attack against a Flash app. These issues are fairly widespread, with over 35% of SWF applications violating Adobe security advice."
if the post -- or even the site -- had mentioned that the tool was for Windows only, so that I did not have to register first and then find out.
"Blinded by Flash: Widespread Security Risks Flash Developers Don't See"
From the presentations description:
"In this presentation I will examine the Flash framework and then delve into the Flash security model and the transitions it has undergone over the years. To explore the avenues of compromise in the security model, I will use a test Flash application and demonstrate various attack vectors including Cross-Site Request Forgery, data injection and script injection. During this demonstration, I will explain the associated threats in detail and discuss means to mitigate these threats. Even though the test application validates the attack surface, the question remains: how many applications actually deployed are vulnerable to these threats? I will answer this question by providing astonishing statistics about vulnerable, real world applications I was able to find using simple Google queries."
The pdf of her presentation is here:
https://www.blackhat.com/presentations/bh-dc/Jagdale/BlackHat-DC-09-Jagdale-Blinded-by-Flash.pdf
He didn't make it very clear in the video, but a decompiler doesn't really give you the original source code to the program. It gives you source code that works the same way and, when compiled, would result in the same binary. However, comments are not included, and it's possible that variable and function names might not be preserved (depending on the language and how the program was compiled). Also, the compiler might have performed various optimizations, and upon decompiling you'd get the source code for the optimized version - for example, the compiler might simplify "x=x+1;" as "x++;" and "y=x**2;" as "y=x*x;".
These are basic concepts for decompilers in general; I know nothing about Flash.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Assuming they have the source code, in the example given, how WERE they supposed to do it? The only thing I can think of is "When they make a query, run a procedure on a database that takes the IP, stores it, and Increments a value ("wins per day")"
Excellent question.
Unfortunately, IP addresses aren't reliable for this purpose. However, in order to win you have to provide your e-mail address, and the coupon is e-mailed to you. The simplest solution would be to store e-mail addresses in the database and (as you suggest) limit the wins per day for each e-mail address. Another idea is to generate a unique ID for each visitor to the site (using cookies), and make sure one user doesn't submit requests with multiple e-mail addresses.
Of course, what's not mentioned in the video is an even bigger potential security hole: if the coupon is supposed to be printed out, and then redeemed for a cheeseburger, there's nothing to stop someone from printing multiple copies of the same e-mail. Unless, of course, each coupon has a unique ID that must be verified against a central database. Most places solve this problem by printing "Limit one per customer" on the coupon, which would apply equally to multiple coupons received from multiple wins of the game.
Now I want a cheeseburger. Excuse me.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
While all of your comments about decompiling are true, the output of this particular decompiler is quite good. Var names remain intact, logical constructs appear valid, etc. I'm no Flash dev, but this looks like the it could be the same code before compilation.
It makes sense if you consider that Flash is an Adobe proprietary "platform" and they can make the compiler and interpreter in any way they please. I really don't know what's involved in the compilation process, but my guess is that it's no where near as complex as a C compiler, for instance. They need to obfuscate the output to prevent reverse engineering (like it did them much good), and make it easier for the client side, and that's about it. To my almost untrained eye, the output looks dead on for the original source.
It's not the exact same code, but it's pretty damn close - nice to see all my Log.debug(); messages make it through in the decompilation stage...
https://h30406.www3.hp.com/campaigns/2009/wwcampaign/1-5TUVE/images/SwfScan.msi
It sounds like SWFScan actually scans flash SWF files, not flash itself like the post suggests.