Using JS2PDFInjector to check risks of PDF files with embedded JavaScript

Lets do a very short script for a play to set the scene for this one. Positions everyone:

CornerPirate: Love PDF? Love your JavaScript? Everyone’s favourite office file format and interactive code engine together!

*interlocks his finger*

CornerPirate: Let’s weave them together. What could possibly go wrong?

What could possibly go wrong indeed. No point dallying you can find out how that could go wrong at these places:

• http://resources.infosecinstitute.com/analyzing-malicious-pdf/#gref
• https://zeltser.com/analyzing-malicious-documents/
• https://www.trustwave.com/Resources/SpiderLabs-Blog/Analyzing-PDF-Malware—Part-1/

These are all way more detailed than I would choose to go on the subject and are worth a read.

Probably a great idea to make sure that your email, and Internet proxy blocks them coming inbound then isn’t it?

This post will show you a tool which can be used to inject JavaScript into a PDF so that you can evaluate your own inbound filtering system’s.

Get the tool

You can get the source and the built jar from the repository below:

https://github.com/cornerpirate/JS2PDFInjector

Download the zip or clone it down it is your choice.

Using it

Goto the “dist” directory and run the jar file. In Windows you can double click on the jar if you have the Java Runtime installed. Alternatively you can run:

java -jar JS2PDFInjector.jar

When it launches it will:

1. Ask you to select a PDF file to inject into.
2. Ask you to select a file containing JavaScript that you want to run when users open the PDF.
3. Create the new PDF with “js_injected_” into the file name and make a new file in the same directory as the original PDF.

Pretty simple I think. It could be a command line tool. But meh I wanted file choosers for some reason that day. You have the source so go fix it if you like.

Creating Payloads

The JavaScript APIs are slightly different from those you might be familiar with in web browsers. In order to understand exactly how to create payloads you are going to need to understand the APIs here:

Click to access js_api_reference.pdf

As a pentester it is usually sufficient for me to simply evaluate the defences strip all JS from a PDF or quarantine the file on the way in. If your solution does not then I can infer that you could be doing more to protect yourself.

So for me it has been enough to go with a simple alert message like this one:

app.alert("Hello world!");

If you want to weaponize this by injecting malicious things, then you do so at your own legal risk and I am not responsible for your actions.

I just felt that if this was in anyway useful to someone then I should share it!

How to use your file legitimately

So you found this blog because you wanted to evaluate your companies defences against PDF’s with malware written in JavaScript? Awesome.

1. Test your Anti-Virus [Local Only Test]
   1. Upload your PDF onto a server or workstation you want to test by USB or whatever works in your environment locally.
   2. Right click and scan with your anti-virus solution and see if it says anything.
   3. The chances are your PDF does not match any signature since you have made it yourself. However, if you have configured a solution which says it “warns when a PDF has JavaScript” or it “quarantines” such files. Check to see that it has found it.
   4. For bonus points if your AV is configured to log events centrally make sure someone has seen the log alert and has kicked off an investigation.
2. Test your Email Filtering
   1. Use an external email address to email your PDF into a work address.
   2. If you have a complex system which has multiple in-line inspection points before it reaches a user. If the email arrives with the attachment intact and it triggers an alert or whatever your payload is in Adobe Reader? Then you should repeat step one (Local AV scan). Your company is at risk as you have found people can email in potentially dangerous PDF files. Repeating the AV scan manually will see if it will ever find that file. At this point the payload has already run and you have been compromised.
   3. If the email arrived but Adobe does not execute your payload. The chances are that you have something in-line before it hits users. This has attempted to remove the JavaScript from the PDF file but leave the original viewable content. Investigate on your filtering systems which component has done this and see if there was an appropriate alert raised and an investigation by a member of staff. This is still evidence that somebody *tried* to target your users.
3. Test your Internet proxy Filtering
   1. Upload your PDF file to an Internet web server. It has to be the Internet because Microsoft’s various web browsers implements a “zone” model for security. The Internet zone is the least trusted so the fairest evaluation.
   2. Download the file in the default web browser for your users going through all Internet proxy and inspection routes.
   3. If the payload executes when opened in Adobe. Then you have found another route to download PDF files with JavaScript onto your target machine from an external source. Repeat step one to see if you have a last ditch defence in the AV. However, it is worth noting that the AV allowed the payload to run so…. hmmmm. You are already compromised and should look at the AV solution.
   4. Again. If the payload did not execute. Try to investigate where in the chain it happened, and then look for staff to have reacted to that alert.

You can take these techniques and alter them for all other routes into your organisation. A file-upload on a website? An SFTP service etc.

Hope that helps