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!
XSS attack by using different protocols in “navigateToURL” redirections:
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!
“jar:” protocol is our invisible friend and a True Warrior!!:
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.
Bypassing local-with-filesystem protection by using “navigateToURL”:
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.
Let’s have some fun! I want to open your CDRom!
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!
Important Update: Adobe Flash has been patched to close JAR protocol issues forever! (http://helpx.adobe.com/security/products/flash-player/apsb14-02.html)