The real dangers of PDF executable trickery

Guest editorial by Jeremy Conway

At first, the possibilities and/or implications for the creative hackery we have all read about this week concerning Didier Steven’s Escape From PDF hack may in fact be under appreciated and/or overlooked.  The beauty of Didier’s proof of concept is that he discovered a method to execute an embedded executable within a PDF file without utilizing any JavaScript and without having to exploit any vulnerabilities.  Didier described how he was able to pass the Windows command interpreter, cmd.exe, parameters that spawned a five part scripting process from within the PDF to carry out his attack on a podcast today hosted by EuroTrashSecurity.  This may seem as if it is just another example of how to execute an executable already residing on a user’s computer, or as Didier did from within the PDF document.  These implications alone probably raise some major concern for most of security engineers and system administrators out there, but there is more that can be done with this hack that may not be immediately apparent.

[ SEE: Hacker finds a way to exploit PDF files, without a vulnerability ]

I have been preaching for a long time now that the methodology utilized for applying incremental updates to a PDF file could possibly be utilized as an infection vector for malware writers and malicious code writers at some point in the future.  Don’t believe me then check out this presentation  I did at a local ISSA chapter meeting back in January of last year titled “PDF: A Vector for Badness Incognito”.

Didier’s discovery was exactly what I was looking for to drive my point home, so I decided to make my own proof of concept which can be seen in a video on my personal blog here: Are PDFs Worm-Able.  In this proof of concept I have one benign PDF document titled “empty.pdf” and another evil PDF document titled “ownit.pdf”.  The ownit.pdf file contains my custom code that when opened prompts the user to allow the execution of this code and if the user clicks “ok” this code will inject an incremental update into the empty.pdf file.

Using Didier’s discovery, we can control the message presented to the end user and turning off JavaScript will not prevent this hack, so it is very likely that we will have some success in pulling this off.  For my proof of concept, I embedded a PDF Launch action that would open Firefox and send the user to my website, but in reality I could have embedded anything I wanted to into the empty.pdf file without changing any of the physical appearances of the empty.pdf document.  This is where the scariness of this hack should really sink in, as my code could easily be adapted or modified to infect every single PDF file on a user’s computer or accessible to the user via network mapped drives without changing the physical appearance of these newly infected PDF files.  This means PDF files that have been stored on the user’s computer for years and are trusted could now house any sort of badness and/or evil I chose to update them with.

To better expand on the possibilities of utilizing incremental updates in a malicious fashion, lets walk through a possible scenario for how this attack could be carried out.  The attacker crafts a malicious PDF document containing an embedded exploit pack that targets multiple previously disclosed PDF application vulnerabilities, which is not all that uncommon today.  If the attacker chooses to use a modification of my proof-of-concept as phase one of a multistage attack, the attacker could seriously raise the probability for success.  Let’s assume the attacker distributes the maliciously crafted PDF document utilizing the common spear-phishing technique of spoofing the sender address of someone the target may know.  Since the attacker has chosen to utilize a modification of my proof of concept to reach out and infect all discoverable PDF files on the user’s computer and distribute the embedded exploit pack as the payload instead of just attempting to exploit the user the attacker can effectively raise the probability that at least one of the trusted PDF files will be further distributed by the user in the future.

[ SEE: Adobe suggests workaround for PDF embedded executable hack ]

Since every single PDF file on the end users computer is now infected with this exploit pack it is only a matter of time before this user distributes one of these newly infected PDF files to another user running a vulnerable version of a PDF rendering application.  It is also just a matter of time before the original user that received the PDF opens one of these newly infected PDF files containing the exploit pack and becoming a victim as well.  Now the exploit pack doesn’t have to be a delayed process as the attacker could have just as easily coded the logic to perform both actions in one quick swoop.

If we add in the complications this style of attack will bring to our incident response teams and processes, we have one nasty mess on our hands.  Let’s say the attack did in fact work and now all PDF files residing on the user’s computer are infected with this malicious code, and that the second stage of this attack is the retrieval of a Trojan from a server out on the internet upon successful exploitation.  It is very likely that at some point in time our anti-virus software or a network monitoring device such as an IDS will detect the Trojan.  This detection will most likely either spawn the incident response team to take action by verifying the Trojan was quarantined by our antivirus software or that the machine is reimaged with our standard corporate image.  Does this really address the situation at hand?  Not really, since both of these responses will not address the infected PDF files that is facilitating the attack, or in simple terms the infection vector.

Even if the system was re-imaged, it is a common practice for the incident response team to back up and restore all files they do not suspect as being malicious and/or involved in the attack back on the users system.  Do you really think the incident response team will suspect every single PDF file on the user’s computer as being involved?  I seriously doubt it.  The other aspect that needs to be taken into account with this attack scenario is that by cleaning the user’s computer the attacker will be alerted to the fact that you have now detected his or her activity since the Trojan will no longer be accessible to the attacker.  This informs the attacker that it is now time to change and/or modify the Trojan being downloaded from the Internet by the exploit pack to evade detection once again and then it is just a matter of time before the user reopens one of those trusted PDF files and becomes a victim once again.

[ SEE: Adobe, FoxIt investigating PDF executable hack ]

As you can see this is one nasty cycle for which most of our standard security and incident response procedures are just not prepared and/or equipped to handle.  Now think of all the methods that could be utilized to distribute a PDF file to unsuspecting users and if that doesn’t cause your head to spin I don’t know what will.  Well it could get worse,  just think if this style of attack was combined with a PDF rendering application zero day attack, now that could spell some serious disaster for most of us.  That isn’t the end either, as the PDF specifications allows interaction with common media players and Acrobat Reader currently allows Flash to be embedded, so zero day attacks on media applications could possibly be carried out from within the PDF.

This feature rich document format has just as many exploit possibilities as it has features, so what can we do about this?  My recommendation is unless you have some specific use case within your business processes for all of these features to change your default PDF rendering application to a striped down version that does not support any of these features.  I don’t really have any specific recommendations on which one to use specifically, so I would recommend doing some research and choosing one that best meets your needs.  Another option is for PDFs readable on the web utilize an online PDF viewer such as Google’s PDF Viewer.  Maybe if we push hard enough or just ask nicely enough we can get some of the major vendors such as Acrobat and Foxit to provide a minimalistic version of their applications, wouldn’t that would be nice?

* Jeremy Conway is a Product Manager for NitroSecurity where he performs threat and security research supporting new product development.