HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

Displaying articles for: March 2009

SWFScan Forum

We now have a forum dedicated to discussing HP's Flash analysis tool, SWFScan. Go there for suggestions concerning usage, tips, and other helpful information and comments regarding SWFScan. The forum can be visited at the following link:

 

SWFScan Forum 

 

To download SWFScan, please visit:

 

Download SWFScan

Exposing Flash Application Vulnerabilities with SWFScan

After months of hard work and late caffeine-fueled nights, HP’s Web Security Research Group is proud to release HP SWFScan.


HP SWFScan is a free Windows-based security tool to help developers find and fix security vulnerabilities in applications developed with the Adobe Flash Platform. The tool is the first of its kind to decompile applications developed with the Flash platform and perform static analysis to understand their behaviors. This helps developers without security backgrounds identify vulnerabilities hidden within the application which cannot be detected with dynamic analysis methods.


Simply, point HP SWFScan at the SWF file for any Flash application and it will:



  • Decompile the ActionScript 2 or ActionScript 3 bytecode back to the original source code.

  • Audit the code for over 60 vulnerabilities including exposure of confidential data, Cross-Site Scripting (XSS) and cross-domain privilege escalation.

  • Validate the Flash application adherence with Adobe's security best practices.

HP SWFScan is not the first free Flash tool. Excellent decompilers such as Flare or OWASP’s SWFIntruder security tool have existed for a few years now. Unfortunately, the capabilities of free tools have not kept up with new Flash innovations such as the introduction of Flash 9 and 10, ActionScript 3, and Adobe’s Flex framework. HP’s SWFScan is the first and only free tool to decompile both ActionScript 2 and ActionScript 3 and analyze them for security vulnerabilities.


In addition, HP SWFScan offers several other features to help developers, code auditor/reviewers, and pen-testers examine the contents of Flash applications, including:



  • Highlighting the line of source code that contains the vulnerability to help better understand the context of the issue.

  • Providing summaries, details and remediation advice for each vulnerability in accordance with Adobe’s recommendation for secure Flash development.

  • Generating a vulnerability report to share and solve the detected issues.

  • Exporting the decompiled source code for use with other external tools.

  • Revealing all the URLs and web services the Flash Application contacts.

  • Flagging class names, function names, or variable names that may be of interest such as loadedUserXml or crypt()

While developing HP SWFScan, we downloaded and audited over 4000 Flash applications. We encountered numerous insecure applications and collected some interesting statistics:



  • Of 250 Flash applications we tested that had a login form 15% had user names or passwords hard-coded inside the application code.

  • 16% of SWF applications targeting Flash Player 8 and earlier contained XSS vulnerabilities.

  • 35% of all SWF applications violated Adobe's security best practices.

  • 77% of SWF applications targeting Flash Player 9 and 10 contained developer debugging information and source code file references.


(You can learn more about how we got these figures in our SWFScan FAQ)


A few things to note: HP SWFScan only looks at the portion a Flash applications that runs inside the browser. This is the SWF file that contains the Flash code Adobe's Flash player executes. It does not look at the components that run on the server. To conduct a complete security assessment of your applications, HP provides a suite of software and services for testing applications throughout the application lifecycle.


Download HP SWFScan


Need Support or have a question about SWFScan? Visit our SWFScan Forum.


Video explanation of a Flash Attack: (AKA, Billy wins a Cheeseburger)

HP SWFScan FAQ

What is HP SWFScan?



HP SWFScan is a free (as in beer)
Flash security tool. The tool decompiles and audits applications written for
the Flash platform.



 



How do you pronounce HP SWFScan?



HP “SwiffScan”



 



Who developed this ing awesome
security tool called HP SWFScan?



SWFScan was developed by the smart guys and gals of HP's Web Security Research Group.



 

I have questions, feedback or comments. Who do I sent that
to?



Please report any feedback,
comments and feature requests to the forum at http://www.communities.hp.com/securitysoftware/forums/612.aspx.



 





Which versions of Flash will HP SWFScan
support?



All public versions of Flash as of this writing. In other words, up to and including Flash 10, though as long as SWF uses ActionScript 2 or ActionScript 3 SWFScan should continue to work.



 

How do I scan my Flash application?



Point it at a URL to a SWF file or
browse to a SWF file on a box and click on the “Get” button.



 



Can I load Flash applications from the
Internet?



Yes. Specify the URL of the SWF
file to be scanned and click ‘Get’.



 



Why doesn’t a link to a webpage decompile
the Flash applications on it?



There are lots of ways to include Flash objects in a webpage. Different tags, different parameters, even using JavaScript. HP SWFScan does not try and auto-magically
identify embedded SWF files in the HTML. You must do this manually. Sorry.



 



How does HP SWFScan find vulnerabilities?



HP SWFScan uses Static Analysis to
detect vulnerabilities.



 



What is Static Analysis?



Magic that was gifted to us by unicorns! Ok, so we didn't get it from unicorns, but really, read Static Analysis on Wikipedia and you'll agree about the magic thing.



 



Is there a way to report on the
vulnerabilities HP SWFScan finds?



Yes. Click on “Create
Vulnerability Report” under the “File” menu. Specify the name of the HTML file in
the “Save File” dialog box and click “Save”.



 



How do I verify the vulnerabilities HP
SWFScan finds?



When the analysis is complete, HP
SWFScan will highlight the source code that is causing the issue. Manual
verification will be required by the user.



 



Why do some of the vulnerabilities not have
any highlighted source associated with it?



In addition to finding
vulnerabilities associated with the ActionScript code, HP SWFScan also audits
the SWF tags in the Flash application. Improper use of SWF tags can also result
in violation of Adobe’s Security Best Practices. Such tags do not have any
ActionScript code associated with them. Therefore, these issues are reported at
the top of the decompiled source tree and do not have any ActionScript source
highlighted.



 



How should I fix the vulnerabilities HP
SWFScan finds?



Every issue reported by HP SWFScan
is associated with a vulnerability report that explains the cause of the issue;
the report also provides the necessary fix suggestions and supplies a list of
additional references to learn more about the detected issue. Also you can read Adobe excellent security recommendations.



 



How long does it take to decompile?



Depending on the size of the Flash
application being decompiled, it may take anywhere from 5 to 30 seconds.



 



How long does it take to audit the
application?



Depending on the size of the Flash
application being scanned, HP SWFScan may take from 10-40 seconds to audit the
application.



 



How much caffeine was really consumed while
developing HP SWFScan?



Approximately 439.6 kilograms of
caffeine were consumed.



 



How can I save the decompiled source?



Click on the File -> Export
Source Code. In the dialog box, specify the name of the file to save the
decompiled code to and click “Save”.



 



Where are the Flash system libraries?



HP SWFScan by default does not
decompile or audit the Flash system libraries in order to optimize decompilation
and audit time.



 



What are exclusions?



When compiled, the ActionScript 2
and ActionScript 3 system libraries are included in the final SWF. When
decompiling, HP SWFScan excludes the system libraries from the decompile
process. However, HP SWFScan allows the user to turn off these exclusions and
add custom exclusions. this is helpful when you wnat to exclude other, 3rd party component libraries.



 



How do I add exclusions?



HP SWFScan excludes packages based
on their names. To exclude a particular package, users can specify a regular expression
that matches the package name to be excluded. To specify custom exclusions,
under the Settings tab, click on “AS2 Exclusions” or “AS3 Exclusions” depending
on the version of the Flash application being decompiled.



 



Can I use a proxy?



Yes, you can. To specify a web
proxy, look for the Proxy tab under Settings. Only simple web proxies are
supported.



 



I want to search for a specific string, how
do I do that?



HP SWFScan provides a search
feature that can be accessed by clicking on the “Search” button on the main
window. The user can choose to either search the entire code or only specific
blocks of code by choosing one of the options on the left bottom corner of the
search window.



 



What is this “checks” thing in the Settings
Menu?



“Checks” represent the
vulnerabilities that HP SWFScan looks for during the audit. Users are allowed
to choose the “Checks” that they want to run against their applications. To do
this, look for Checks under the Settings tab and select the desired ones.



 



Why does the decompiled source say “//Failed
to decompile source”?



Handcrafted SWF files generally
contain control structures that cannot be correctly represented using the
ActionScript language. Blocks of code with these odd structure cannot be successfully decompiled by HP
SWFScan. However we can often decompile other parts of the SWF file. Users will be notified of such a failure by inserting the “//Failed to
decompile source” comment.



 



Which versions of ActionScript will HP
SWFScan support?



HP SWFScan supports ActionScript 2 and ActionScript 3.

 

What about ActionScript 1?



It kinda doesn't exist. Its weird. We don't understand.



 



Does HP SWFScan validate the vulnerabilities
it finds?



No. SWFScan is a purely static
analysis tool and does not perform any dynamics analysis to validate the
detected vulnerabilities.



 



How did you collect your statistics about
vulnerable Flash applications?



We collected over 5000 SWFs by searching Google using the search query
"filetype:swf" plus some random generic keywords. Of those we tested 3954. Of those 3954 Flash
applications we tested, 551 are ActionScript 3 (Flash version 9 or 10) and
3403 are Action Script 2 (Flash 8 and below).



 



XSS Number:



Only ActionScript 2 can contain
FlashVar-based XSS vulnerabilities. Of the 3403 AS2 Flash apps, only 633 had
code that could be XSS-able (specifically function calls to things like getUrl
with user supplied input as parameters). Of the 633, We found that 99 contains
XSS vulnerabilities. We manually confirmed these issues.



 



Debugging Number:



426 of the 551 Flash applications
version 9 or 10 made calls to trace() debugging function or contained debugfile
and debugline opcodes. We excluded all the standard Adobe functions and looked
only at user created code to ensure that only user supplied debugging data was
analyzed.



Best Practices Number:

1381 of the 3954 Flash applications contained at least one of the following issues defined in Adobe's Creating more secure SWF web applications:

  •  Contained XSS
  • Contained debugging information
  • Stage was too small
  • Insecure Cross-domain permissions
  • Obsolete/insecure protection mechanisms like PROTECT, ENABLEDEBUGGER, etc

 



Will HP SWFScan audit the server scripts
used by the Flash application?





No. HP SWFScan only audits the
client side code of the Flash applications.


Where can I learn more about Flash security?



A few resources that will help
users to learn about Flash security are:



http://www.adobe.com/devnet/flashplayer/articles/secure_swf_apps.html



http://www.owasp.org/index.php/Category:smileysurprised:WASP_Flash_Security_Project

Tags: SWFScan

Join the ASC groups on LinkedIn and Facebook

We'd like to invite you to join the new ASC groups on LinkedIn and Facebook. We’ll be posting videos, whitepapers, press releases, articles and other things there of interest to the security community.    

 

LinkedIn: http://www.linkedin.com/groups?viewMembers=&gid=1851238&sik=1237318704088

 

Facebook: http://www.facebook.com/home.php?#/group.php?gid=57440939557&ref=nf

 

HP’s Application Security Center helps protect businesses from malicious hackers through a full suite of application security software and services that enables customers to find, fix and prevent security vulnerabilities across the application life cycle. We are dedicated to researching, innovating, educating and improving our products and services to address the latest application security threats, trends and issues.


 

Diamond heist holds infosec lessons, too

Wired is running the story “The Untold Story of the World's Biggest Diamond Heist” on their site and in the next issue. You may have already read it, since it’s pretty popular on the tubes right now. If you haven’t—while it’s pretty long—it’s an interesting read on physical security, criminals, capers and exploitation of weaknesses.

 

Below is a fairly spoiler-iffic view on the heist and how I think it relates to the information security world—so if you want all the gory details without my summary, head over to wired.com first.  Here’s a high-level synopsis: in an Italian Job like caper, a group of thieves do the seemingly impossible by robbing a massive vault in Antwerp’s diamond district. This is no ordinary vault—it holds most of the district’s diamonds and other valuables, and has a significant amount of security, including the following (there is also a diagram of this):   

 

  A 3 ton steel door with:


  • Combination dial (0-99)
  • Keyed lock
  • Seismic sensor (built-in)
  • Locked steel grate
  • Magnetic sensor
  • External security camera

 And inside the vault:


  • Light sensor
  • Security camera
  • Heat/motion sensor

This vault is also located in the basement of a guarded and monitored building, and in the middle of a diamond district that is blanketed with security cameras and has its own specialized police force.   

 

 Seems impossible to break into, right? Of course not.   

 

The story, as told by Leonardo Notarbartolo (serving 10 years in jail for his part in the crime), tells of how a small group of men exploited minor weaknesses in the various layers of security, and walked away with an unknown amount of wealth (read the article as to why it’s unknown)… and very nearly got away with it.   

 

While this isn’t directly web/network/data security related, their tactics, from reconnaissance to exploitation, have a lot of parallels to the computer security realm. The methods they use are the same pen-testers and criminals are using against our networks and applications.   

 

  

Reconnaissance

Notarbartolo used a small “spy” camera to document the building and vault. They studied the monitoring systems, vault, building, surrounding buildings, entrances (conventional and otherwise) and habits of the guards. They sneaked in a small spy camera to capture the vault combination (key logger, anyone?) which went to a transmitter hidden inside a fully functional fire extinguisher.   

 

Social Engineering

Notarbartolo set himself up as a dealer in the building, and rented a box in the vault. After a time, the guards came to recognize and almost ignore him, which gave him a critical opening to disable a heat detector inside the vault.  

 

Preparation

The thieves set up a fake vault to practice in and to look for new weaknesses (pretty sure this was in one of the Ocean’s <insert number here> movies). Professional testers make no secret of the work they do against “fake vaults” (ok, lab systems) looking for 0day vulnerabilities to use in their products and future engagements.  

 

Exploiting Small Weaknesses

There was no single, major flaw in the security. There was no brute force attack (portions of the movie Heat come to mind). Like gaining access to a less-secure and less important “system” (an adjacent building with a courtyard), they had unmonitored access to the secure building’s exterior. They used a little stealth with a home-made polyester shield to defeat a heat and motion sensor, a piece of aluminum and duct tape to defeat a magnetic sensor, and while they had a duplicate key crafted based on the video tape they’d made (which smacks of SNEAKY), they found the actual key in a nearby room (password under the keyboard, or console access?). Black bags covered video cameras which were expected to show darkened stairways. Hairspray defeated a motion and heat sensor long enough for them to disable it completely.  

 

All of these tiny weaknesses and crafty exploits combined into a massive heist. The tiny chinks in the armor turned into a significant financial loss for the owners of the lockboxes and their insurers.   

 

Lessons 

So what lessons can be gleaned from the physical-security weaknesses, and translated into the digital world? Plenty.  

 

First off, no vulnerability or weakness can be completely ignored. Decisions based on risk and cost can be made, and fixes prioritized, but everything should be discovered, catalogued and tracked—at some point that “minor” flaw could be very important. Knowing every weakness and monitoring for exploit attempts could be critical in stopping a massive breach.  

 

Secondly, there is no such thing as an unimportant application or system on your perimeter (maybe even your internal network). Just because your Job Listing application doesn’t hold customer data doesn’t mean it isn’t critical to your perimeter security. Even if the app runs on a different web server, what if there is a flaw that gives someone system access? Is the root password the same one as in on your banking systems? Does the system give the attacker access to the same DMZ that your critical data traverses? Is your security staff monitoring the IDS as closely for the “ATM Locator” system as the bank login?  

 

Thirdly, security is not a one-time effort. Your security efforts may be baked in from planning to implementation, but they don’t stop there. Threats, attacks and techniques are constantly being discovered and are always evolving. Since the criminals knew, it seems possible the manufacturer of the heat and motion sensor knew of the “hairspray exploit” but didn’t bother to warn their customers and issue a “patch”—or maybe they did, and the operators of the vault chose not to implement a fix.  

 

And lastly, to the best of your ability, you have to think like a criminal. You may even consider hiring someone (permanently or on contract) that can do that pretty well (I won’t debate hiring actual criminals). Would someone used to breaking into vaults ask “Why the heck is the magnetic sensor mounted on the outside of the vault door?”  I’d hope so. Would they have scouted the nearby buildings looking for an attack vector? Perhaps. Would they have questioned the wisdom of having video cameras watching completely dark rooms? Any one of those questions, posed to site security or management, could have triggered a corrective action that might have stopped this entire heist in the planning phase.   

  

So, the next time you think you have better things to do than fix that minor cross-site scripting issue on that little loan calculator application—reconsider—and wonder if Leonardo Notarbartolo learned any computer hacking skills in prison.

 

And, I mentioned that Notarbartolo is in jail, which means they didn’t get away clean. Check out the full article as to why… that interesting bit, and a lot of other details and theories that I didn’t get into, make it a good read even after skimming this.

 

Search
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
HP Blog

HP Software Solutions Blog

Featured


Follow Us
Labels
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.