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 RestrictionsStatus: 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.
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
Before I am going to explain the vulnerability you should have a look at another vulnerability
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.
Lets have a look at the following pre defined function:
We can influence doc.path.match and let it point to our trustedproperty function.
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.
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.
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.
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.