Slashdot Mirror
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."
Can they also make SFWScan?
That would help avoid potentially embarrassing situations at work.
There's no -1 for "I don't get it."
Unless they make it into a Firefox plug-in that checks the flash code before running it, just what good is this?
I'm an American. I love this country and the freedoms that we used to have.
Paranoid much? This is for Flash developers to avoid doing stupid things with an app that endangers their site, perhaps with a few checks to help avoid exposing their customers to additional risk. Why on Earth do you think there is an ulterior motive here?
Keep in mind there are already loads of .NET security analyzers out there. TFA notes that the current Flash analyzers are frequently not up to date with the latest Flash releases. Is it so horrible of them to try and be helpful?
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
It's safe to assume that no one actually uses Silverlight so this would be a moot point.
You can't take the sky from me.
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
Though I haven't had a chance to evaluate it just yet, I think this is a step in the right direction. Flash security is often overlooked, while Flash itself is often overused by designers who think that pretty effects make the web page. It gets especially bad when Flash is used for activities that require some sort of security, such as a login form. 99% of the time, instead of POST'ing that information to a server side script, it's handled inside the SWF file. Since these can be easily decompiled (grab a copy of Flare or any other decompiler), the password is easily revealed. I recently found a network product which went through the trouble of XOR'ing a password and storing in a text file. Two problems: the text file was in the web root, and the XOR key was inside the SWF. Tools like this can only raise awareness of these types of issues.
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;
So naturally my first thought was, I wonder how well youtube does.
And lo: it's got 7 vulnerabilities.
It's interesting how this behemoth of a flash provider is still not secure.
*reaches for tinfoil hat*
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.