The real dangers of PDF executable trickery

The real dangers of PDF executable trickery

Summary: There is more that can be done with this latest PDF hack that may not be immediately apparent. We could start seeing persistent PDF worm attacks.

TOPICS: Security

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”.follow Ryan Naraine on twitter

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.

Topic: Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • it's just on windoze

    Linux is safe and can be made unbreakable by App Armor.
    Linux Geek
    • Unbreakable? Is that like "unsinkable"?

      Besides, if I understand this attack it is NOT limited to Windows, the same mechanism for launching exists inside Linux versions as well.

      It's part of the *specification*, not the *implementation*.
      • The attack itself must be geared towards a specific OS.

        And, as MS proponents are ever so eager to point out; "Windows currently has the highest market share, so there'd be no point making a Linux trojan".

        So for all [i]practical[/i] intents and purposes, it's safe to say Linux users need not worry about this particular vector.
        • Apple's PDF viewer...

          and consequently OSX are immune to this malware hack.
    • No, it isn't.

      No, it isn't. This functionality of PDF files is
      actually by design and would likely not be
      prevented by AppArmor.
      • It could be prevented from changing any of your files, though.

        And from reading anything but your PDFs.
      • But The Point Is

        In windows if an application fails the OS is a risk because of poor design. This is not the case for most other operating systems.
      • 3rd party viewer

        So don't use a viewer that supports these exploitable features. I find "xpdf" to work well for this.
  • Cave man easy

    [i]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?[/i]

    Less is sometimes more. That's why they'll never go for it (at least, I won't hold my breath waiting).
  • Ubuntu Linux opens PDFs in a secure sandbox

    Be safe with Ubuntu Linux 10.04 LTS, coming April <strike>30</strike> 29, 2010

    <a href=""><i style="display:block;width:180px;height:150px;background:url();">?</i></a>

    Entschuldigung Sie bitte
    • Does it?

      This is news to me, how do you know this? A link to info would be helpful. I was hoping Mr. Schnitz would chime in w/ an app armor related command, but if you're correct, then I needn't bother. BTW, 10.04 is already in the house. The Vbox test was very good, so I've already done the: sudo do-release-update -d
      • I believe that was indeed Mr. Schmitz

        He was what you humans call "outed" a few months back.
        Tim Cook
  • Sumatra PDF?

    Is Sumatra PDF lightweight enough?

    I've been using it for a couple of years now since I got tired of Adobe Reader's intrusiveness introduced about version 5.

    I mean, I get very suspicious when a viewer application requires a reboot after an update or install -- its obviously doing things I don't need and messing with system things it probably shouldn't!
    • Sumatra PDF

      Thank you. Sumatra is now my default PDF reader. The only thing I would like that is not there is the ability to change the color of the background (outside of the document) in full screen mode. Oh well, you can't have everything.
  • PDF good for read only, Adobe needs a new delivery platform for interactive

    PDF is good for read only, presentations and getting publications ready for print

    Flash is great for front-end web apps and the like.

    Adobe needs a new delivery platform for interactive media. Perhaps they can team up with someone who has such a platform ( I can think of a few - I know most can as well)
  • RE: The real dangers of PDF executable trickery

    "Another option is for PDFs readable on the web
    utilize an online PDF viewer such as Google?s PDF

    Disagree. Browsers tend to be huge targets for
    attacks. Close one hole, open up a bunch more.

    "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."

    It's an issue that needs to be resolved, like every
    other issue.

    And no, I generally do not admire hackers, no matter
    how creative they are. They don't deserve admiration.
  • I suspect there's yet another PDF vector

    If you have Acrobat, you can include other files as attached comments or attached files. If a PDF file has been made commentable, you can do the same thing using Reader. Acrobat says it won't open attached .vbs, .exe, or .zip files, but that leaves a lot of other vectors.
  • Main problem is Adobe

    The main problem is Adobe - they're bloated, non-responsive, and out of touch with things - living in their own little world where they think they're the center of the universe

    They keep shoving intrusive bloatware at everyone and as long as 64-bit OSes have been readily available, still don't have a Flash version compatible with 64-bit browsers.

    Both good and bad - good in that bloated Flash craplets don't pop up all over pages where you really don't want them - bad in that you have to switch to a 32-bit browser to get go to a site you're willing to suffer Flash in order to access
    • Main Problems

      I have to agree with you on this.
      They (like the OFF folks) seem to have had the ear of MS since the get-go for strategic advantage and the chickens appear to be coming home to roost.
      Don't get me wrong, its ubiquitous and I've thrown my lot into it as the first OS in the universe for ordinary mortals (*NIX - all flavors - just seems to be too esoteric for us lesser beings).
      I've worked most stuff from complex CPU chip-designs, to nics, kybds, and mice, X-Windows, and even an NOS's NET.EXE!
      And never has it been so unpleasant to have to generate the requisite and hypnotic interest, attention, and raw excitement in the computer neonate of any age (cub scounts to retired seniors).
      I feel like I am leading them to slaughter.
      And, I am *not* giving up.
  • Yet another reason run in least privledged mode.

    I assume but do not know whether this attack would work if the user did not have rights to install software. Mark all your pdf's as read only and assign ownership to "nobody". That way you and anybody that has your rights will not be able to mod the pdf's.

    It would be nice if the browser or the email client would do this
    automatically before running acroread.