How to safely view a malicious PDF?

Question

I have a PDF with important information that may contain malware. What would be the best way to view it?

Answer 1

Document-based exploits are directed not at the document itself, but rather at some vulnerability in the viewer. If you view the document in a program that isn't vulnerable (or in a configuration that inhibits the vulnerability), then you won't be exploited.

The real issue is knowing whether or not your viewer is vulnerable, which usually means knowing specifically what the exploit is. But there are alternate PDF viewers such as foxit or even Google chrome's built-in viewer that do not necessarily have the same vulnerabilities as Adobe's official viewer. This is not necessarily true for all vulnerabilities, so it's important to understand what you're getting in to ahead of time.

EDIT
If you find yourself frequently dealing with potentially malicious materials, it would be very wise to set up a hardened virtual environment. I'd recommend booting into a Linux system and running your target OS (usually Windows) in Virtualbox or a similar environment. Save a snapshot of the virtual OS, and then revert to that snapshot after you're done interacting with the malicious content. Also, it's not a bad idea to run the host Linux environment from a read-only installation (i.e. Live-CD).

Answer 2

Put it through a PDF viewer that isn't vulnerable to the exploit. If it's someone else's viewer, that's even safer. Try Google Docs, where they will parse it and display it as HTML, so the malicious payload won't harm you. (I'm sure that their PDF parser is extremely secure, so you shouldn't feel bad about possibly infecting them.)

Answer 3

Use pdf.js with a sandboxed browser (such as Chromium or Firefox) in a virtual machine without network access.

It should be quite tricky for malware to get out of this.

Answer 4

A simple and straightforward way to open possibly malicious PDFs on a Windows computer is to use the Sumatra PDF viewer. Sumatra is a small, lightweight PDF viewer that has no support whatsoever for interactive fillable forms or javascript in PDF files.

Sumatra also has configuration options to lock it down even further, such as preventing file system or internet access.

The PDF file format has many interactive features intended to make the format more useful, but which create significant security risks, including:

• The use of javascript to provide interactive content , which allows automation of the user interface
• The ability to interact with the local file system
• the ability to issue an HTTP request to a remote server
• the ability to carry a payload of arbitrary file attachments, including malware
• the ability to present a fillable form to the user, and then capture and act on the information filled in

These abilities combined together make a powerful toolkit for an attacker. Many so-called "drive-by download" attacks rely on the use of PDF files.

Common PDF viewers attempt to provide safety for these features by creating sandbox environments or giving the user prompts, but these solutions are both more complex (and therefore subject to their own vulnerabilities) and less compatible with other parties' products than the simpler solution of leaving out that functionality entirely.

Sumatra is one example of a PDF viewer that does not provide many of the functions which are most commonly used in PDF exploits. By completely eliminating entire categories of potential attacks, such programs greatly reduce the risk of viewing unknown PDF files.

A further advantage of using a less popular viewer is that because it's both less common and less powerful, it's a less interesting target.

The Sumatra viewer could be possibly be exploited by a specially crafted PDF which takes advantage of some unknown bug to cause a buffer overflow, for example. Such cases are rare however, and there have not been any significant security exploits for Sumatra in recent years.

Answer 5

In this situation I've always used the Unix/Linux/OSX shell command "strings". On *nix systems, do this:

strings ScaryFile.pdf | less

You can also get "strings" for Windows, as mentioned by Polynomial, below. You can download it here. Runs on XP or higher. Here is an example of using it on Windows:

strings ScaryFile | findstr /i TextToSearchFor

But for the rest of my answer here I'll assume you're on *nix, since that is my experience with strings. Assuming all you're looking for is text content (not bitmaps or vector graphics), you can scroll down or search and find bits of the text you need. Unfortunately, to find it you have to wade through tons of metadata, most of which is in XML, and formatting settings in some other markup, plus some binary (as ascii, not raw bytes). So you may want to use the search capabilities of the "less" command. To search down the document for the case-sensitive string "thingyouwant", use the slash key + your string + return:

/thingyouwant

Then hit the "n" key to see the next instance of "thingyouwant", over and over till you find what you want. You can use the "?" key to do the same thing in the upward direction. See the less man page (type "man less") for more magic.

You could also analyze things like which URLs the document links to:

strings ScaryFile.pdf| grep -i "http" | sort | uniq | less

But, as stated above, 99% of what you'll see from the output of "strings" is going to be metadata and formatting settings.

Answer 6

Use a virtual machine that can be reverted to clean slate after tests. If the PDF reader is vulnerable, your real workstation will be much less likely to be affected.

Answer 7

Latest versions of Adobe Reader (version 10.1 and up) support "Protected Mode" or sandboxing which can be used to view untrusted PDF files. This effectively restricts the access of the process displaying the PDF file to %appdata%\Adobe\Acrobat and other PDFs which are explicitly opened by the user.

Protected mode has to be activated by going to Edit->Preferences menu and selecting either General or Security tab, depending on the version:

Obviously, you'll want to close any sensitive PDFs like your bank statements before opening the untrusted one.

Answer 8

We can say ALL of the in-the-wild or targetted attack using malicious PDF file are covered with obfuscation techniques to hardened the analysis or detection process.

Most of the obfuscation technique are mainly using JavaScript obfuscation like eval(), String.fromCharCode(), arguments.callee(), base64, and even with PDF key values such as /Author, /Keywords, /CreationDate and etc.

We might unable to view the content of the malicious PDF file (those within the PDF object stream) as it might be deflated commonly with FlateDecode. But there are tools available to allow us to inflate the content within the PDF object stream, such as pdf-parser (http://blog.didierstevens.com/programs/pdf-tools/) and FileInsight (http://www.mcafee.com/us/downloads/free-tools/fileinsight.aspx). Most of the obfuscated JavaScript code will lies within the inflated PDF stream.

We can advise you to get the latest patched version of PDF reader with turned-off JavaScript functionality to open the file, but the good solution is to get a virtual machine where you can delete it or revert the snapshot after opening the file.

Answer 9

Another easy and less time consuming option is to open it in the Sandboxie app, which would isolate it.

Answer 10

You can open the PDF in a container. Here's a docker image you can use: https://hub.docker.com/r/chrisdaish/acroread/

MY_PDF_DIR='/tmp/foobar'
docker pull chrisdaish/acroread
docker run  -v $MY_PDF_DIR:/home/acroread/Documents:rw \
        -v /tmp/.X11-unix:/tmp/.X11-unix \
        -e uid=$(id -u) \
        -e gid=$(id -g) \
        -e DISPLAY=unix$DISPLAY \
        --name acroread \
        chrisdaish/acroread

This will open an Acrobat Reader that will display via the local X server.

The approach reduces the attack surface, but not 100% safe as it's got access to your X server.

Answer 11

You can use a less popular viewer/OS combination. I guess no one targets Okular running on FreeBSD (though it can still be vulnerable), so if you open the file in a VM you should be very safe.

In order to do harm the rogue payload must match the viewer version and the OS and the CPU architecture of course. It is really low-level assembly and memory stuff (the payload expects to be placed at a particular memory address and expects some standard system functions to be available). If you change any of those, then the payload may not execute properly (or the viewer may simply crash without doing harm).