2009-12-01
Abstract
We have seen a notable escalation in web-based attacks over the past few years, especially with regard to malicious Flash files - which are capable of redirection, execution of embedded malicious code and exploitation via vulnerabilities. Here, Ken Dunham provides an overview of the behavioural analysis of Flash files.
Copyright © 2009 Virus Bulletin
A notable escalation in web-based attacks has been seen over the past few years, especially with regard to malicious Flash files. Flash files are capable of redirection, execution of embedded malicious code and exploitation via vulnerabilities that exist in certain versions of Flash. Analysis of Flash files can quickly be made more complicated through the obfuscation of bytecode within malicious files, using common JavaScript obfuscation techniques in addition to professional tactics for obfuscating entire files to hinder analysis. Static and behavioural analysis can provide incident response teams and malcode researchers with a quick indication of the possible malicious activity associated with Flash files.
Flash files have a MIME type of application/x-shockwave-flash and contain one of two possible header values: FWS or CWS. FWS represents a normal Flash file while CWS represents a compressed Flash file (SWF). Compression is very common and can be seen in the example shown in Figure 1.
The general format of a Flash file begins with the header, an eight-bit version number, and a 32-bit file length field:
[FWS/CWS] [Version] [Length] [Header] [[Tag Code + Length] [Tag Contents]]
Tags within Flash files may contain a variety of media such as image files, ActionScript, video streams, buttons and JavaScript. ActionScript and JavaScript are frequently the focus of malicious research. It is also advisable to look for unknown and undocumented tags within a Flash file which may be corrupt or have malicious content.
A variety of tools exist to analyse Flash content. Some are limited to working only with older versions of ActionScript when such content is present in a file. Others only work to decompress compressed (CWS) Flash files so that the decompressed file (FWS) can then be analysed with other tools. There are a select few applications that are solid choices for triage of potentially malicious Flash files. While these tools fall short of in-depth reverse engineering and deeper analysis, they are excellent choices for the busy professional seeking to quickly triage potentially hostile content and/or egress communications.
Two free online scanners stand out above the rest for rapid triage of code. Wepawet and Adopstools are both excellent tools for the analysis of Flash files. In some cases dynamic analysis is also available.
Wepawet: http://wepawet.cs.ucsb.edu/. Wepawet enables a researcher to upload both files and URLs that point to potentially hostile content. This is an excellent option for both real-time analysis of a threat or string extracted from an IDS log as well as incident response and/or forensic investigations that may turn up potentially hostile Flash content. At the time of writing this article, the scanner does not support dynamic analysis of Flash 9 files.
Static output from the tool includes possible malicious methods (such as ‘Loader.loadBytes method detected’), hash, submission and process date and time, and Flash version. It also includes a VirusTotal scan report and any URLs referenced in the file. Note that it is common for legitimate Adobe.com URL references to be found in such code.
Figure 2. Wepawet analysis of a hostile SWF file reveals several GetURL addresses and other malicious identification.
Adopstools: http://www.adopstools.net/index.asp? section=tools&page=clickchecker. For the Adopstools scanner the results are split into five sections: header and resources, preview and click test, tags list, GetURLs and ActionScripts, and dumping code. The last two are especially helpful for a busy professional attempting to identify any possible malicious URLs or scripts. Unfortunately this scanner can be a bit slow at times. The interface is more raw-code-analysis-oriented than the GUI-based Wepawet scanner.
Note: If you upload a defanged file such as badfile.swf_ this scanner will display a warning that it’s not a Flash file, but it will proceed with scanning if the ‘Scan’ button is selected.
Identification and capture of potentially hostile scripts and/or URLs is critical for a security researcher. It is common at this point to attempt to capture code related to all possible remote files or links related to the Flash file for domain and abuse research, and/or de-obfuscation of extracted scripts of interest.
Eltima offers one of the most easy-to-use, robust GUI applications for Flash analysis. The program enables a security researcher to quickly identify tags and scripts, and also to export scripts of interest. If Adobe Flash Studio is installed, editing of FLA files (Flash Source) is also supported. ActiveX must be installed in order to use this program. Figure 4 shows how non-obfuscated URL content is clearly revealed via scripts decompiled by Trillix.
Figure 4. Trillix decompiles and displays scripts as well as running the Flash file via preview mode.
Caution: this program runs Flash file content dynamically by default. Be careful only to run this within a Windows lab environment to avoid accidental damage to other systems.
URLs or scripts of interest can be exported simply by using copy and paste or by using the ‘Extract SWF objects’ button. When the extraction option is used Trillix automatically extracts all scripts by default to a working directory and then displays that directory in a new window. For example, the case illustrated in Figure 4 resulted in Frame 0 and Frame 20 exports and associated ActionScript (.as) exports which contain getURL statements such as the following:
//Action tag #0 getURL(“hxxp://5173vip.seawww.cn/cuteqq.htm \r”, “_blank”); text = “?!”;
Script analysis is becoming increasingly difficult as both the ability and adoption of techniques for obfuscating scripts within Flash files advances.
Flash Tracer is one of the easiest ways to dynamically analyse the behaviour of a Flash file – once you get it set up properly. The set-up can be a bit tricky, requiring the installation of a Flash debugger, flashtracer.xpi for use with Firefox, and then a special configuration file. A debugger version of Flash sends output from the trace() method to a log file which is then viewed with the Flash Tracer extension within Firefox. If a non-debugger version exists, uninstallation of the player is required for a debugger version to be installed.
Caution: this results in a dynamic execution of Flash content. Be careful only to run this within a lab environment to avoid accidental damage to other systems.
The following is an overview of how to install Flash Tracer on a Linux operating system such as Ubuntu. Three core steps are followed: installation of a debugger version, mm.cfg creation, and Flash Tracer installation and use.
Go to http://playerversion.com/ and view the report to see if Flash is installed and if a ‘debugger’ version exists.
If a Flash Player is installed but it is not a debugger version, uninstall it using Synaptic or other Linux tools.
Install Flash Player Debugger for Linux by downloading it from http://www.adobe.com/support/flashplayer/downloads.html. Extract files and navigate to the /plugin/debugger directory. Run the ‘flashplayer-installer’ in the terminal and follow the prompts to complete the installation.
Go to http://playerversion.com/ and confirm that a Flash Player ‘debugger’ version is installed correctly.
Create a log file by running a Flash file or creating it as a placeholder for the debugger. Locate and run a SWF file or create a placeholder at /home/{username}/.macromedia/Flash_Player/Logs/ flashlog.txt. Replace {username} with the current user account name for Linux.
Create a file in the home directory for Linux called ‘mm.cfg’ with the following data:
ErrorReportingEnable=1 TraceOutputFileEnable=1
Download and install Flash Tracer from http://www.sephiroth.it/firefox/flashtracer/. If you saved it as a file, drag flashtracer.xpi over Firefox and restart Firefox after installation.
Open Firefox and configure Flash Tracer to point to the flashlog.txt file, replacing {username} with the user name for the current account: /home/{username}/.macromedia/Flash_Player/Logs/ flashlog.txt. Note: be sure to show invisible directories in the Home folder of Linux (right-click on the directory listing window) to browse to flashlog.txt file. You may also just type in the path manually and click OK.
Load a hostile SWF and watch Flash Tracer read the trace() output to the Firefox sidebar. Note: any changes you make using this tool directly impact the flashlog, such as clearing the log file as you clear the Flash Tracer window.
Flash Tracer options are intuitive for pausing and clearing log file displays. Analysts should be looking for URLs that display, possibly pointing to remote exploit sites or redirected targets, and other actions such as getURL statements and undefined tags. Help with interpretation of debugger comments can be gained from the runtime error research published at http://livedocs.adobe.com/flex/201/langref/runtimeErrors.html. For example, FScommand and getURL issues that may exist in a suspect Flash file may be linked to JavaScript actions and egress communications as shown in the Flash Tracer example below for a known hostile file:
*** Security Sandbox Violation *** FSCommand halted (AllowScriptAccess is ‘’): FSCommand:showmenu
Common ActionScript references of interest for hostile activities include but are not limited to FSCommand, getURL, LoadMovie, LoadMovieNum, ExternalInterface, navigateToURL and URLRequest.
More information on Flash security as a whole can be found at https://www.flashsec.org/wiki/Main_Page.