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(); fuckery
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.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:
http://gdata.youtube.com/crossdomain.xml
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”> |
| ? | <cross-domain-policy> |
| ? | <site-control?permitted-cross-domain-policies=”all“/> |
| ? | <allow-access-from?domain=”*”secure=”false“/> |
| ? | <allow-http-request-headers-fromdomain=”*”?headers=”*”secure=”false“/> |
| ? | </cross-domain-policy> |
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:
_root
_global
_level0
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 callingjavascript: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:?data:text/html;base64,PHNjcmlwdD5hbGVydCgxMzM3KTwvc2NyaXB0Pg==
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:
a="get";
b="URL("";
c="javascript:";
d="alert('XSS');")";
eval(a+b+c+d);
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:
”));throw_error()}catch(e){alert(document.domain))}//
”);function%20someFunction(a){}prompt(1)//
although in some cases,a simple?alert`0`?(with template strings) or?’);alert(document.domain);?will suffice. Some examples ofexternalInterface.call?being exploited for XSS can be seen with the plupload/swfupload XSS,example:
http://btpa.police.uk/wp-includes/js/swfupload/swfupload.swf?movieName=”%5D);}catch(e){}if(!self.a)self.a=!alert(document.domain);//
another (more recent) example of XSS via?externalInterface.call?would be theflashmediaelement.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:
http://www.defense.gov/desktopmodules/SharedLibrary/Plugins/MediaElement/flashmediaelement.swf?jsinitfunctio%gn=alert`
[XSS]`
?
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’??
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.
?
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
MFW they’re actually making people PAY MONEY for this piece of shit software
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” |
| ? | transitionSpeed=”.7“ |
| ? | transitionType=”Fade“ |
| ? | motionType=”None“ |
| ? | someParam=”blah” |
| ? | anotherParam=”Blah” |
| ? | <imageimg=”/Images/Backgrounds/01.jpg”?caption=”” /> |
| ? | <imageimg=”/Images/Backgrounds/02.jpg”?caption=”” /> |
| ? | <imageimg=”/Images/Backgrounds/03.jpg”?caption=”” /> |
| ? | <imageimg=”/Images/Backgrounds/04.jpg”?caption=”” /> |
| ? | <imageimg=”/Images/Backgrounds/05.jpg”?caption=”” /> |
| ? | <imageimg=”/Images/Backgrounds/06.jpg”?caption=”” /> |
| ? | </slideshow> |
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:
| <slideslow> | |
| ? | <imageimg=”javascript:alert(‘XSS@’%2Bdocument.domain”?caption=”” /> |
| ? | </slideshow> |
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,recieved 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
