Slashdot Mirror
Ask Slashdot: How Do You Automatically Sanitize PDF Email Attachments?
First time accepted submitter supachupa writes "It seems the past couple of years that spearfishing is getting very convincing and it is becoming more and more likely someone (including myself) will accidentally click on a PDF attachment with malicious javascript embedded. It would be impossible to block PDFs as they are required for business. We do disable javascript on Adobe reader, but I would sleep a lot better knowing the code is removed completely. I have looked high and low but could not find a cheap out of the box solution or a 'how to' guide for automatically neutralizing PDFs by stripping out the javascript. The closest thing I could find is using PDF2PS and then reversing the process with PS2PDF. Does anyone know of a solution for this that is not too complex, works preferably at the SMTP relay, and can work with ZIPed PDFs as well, or have some common sense advice for dealing with this so that once its in place, there is no further action required by myself or by users."
At some point you trust technology and also reinforce proper user behavior. I hate catch-phrases but your e-mail hygiene should have layers of protection (defense in depth). Assuming that the message got through IP reputation filters, SPAM analysis, malware scans, and was delivered to your user, you rely on desktop protection and cross your fingers that nobody opens it.
We have SMTP appliances from Axway and we used to stop all executable attachments and deliver a notification to the user to call the help desk and request a release. Times changed and we don't do that any more. However, you could annotate the message to remind the user that if they don't know who it's from or what it is or if they weren't expecting it to not open it. And some will anyway. We also used to hold certain attachments for four hours until the virus definitions (and the other defenses) received a couple of updates and then reprocess the message.
If you do try to roll your own, be aware that everyone and their dog creates PDF files with varying degrees of success and we had certain PDF files that caused services to fail on our gateway while they tried to scan and process them. You didn't mention the volume but make sure your solution scales well.
Sadly a lot of PDF printers will retain javascript code even if you print it and re-assemble it back into a PDF. The problem lies in the fact that Adobe allows javascript to be embedded inside image objects and compressed blocks of PDF binary. It's not as simple as opening the file and stripping out anything that starts with . Code can be fired on almost any user event and it can be attached to almost any high-level object. It's not impossible to create a scrubber but it's a lot more complicated than you might think.
I spent the better part of a week attempting to create a PDF scrubber at my office for this same reason. We had become victim to highly targeted attacks from PDF sources. I wrote a scrubber in PHP using an open-source PDF parser and a series of regular expressions to strip out any javascript. At the end of the day, I came very close to a working solution but I ran into issues with encrypted PDF's.
The project was shelved in favor of making users open all external PDF's on a virtual server that was hardened and re-imaged every evening to prevent any malicious code from running rampant. That's the simplest solution.
There's a couple of vendors (and many more playing catch-up) selling appliances that detonate attachments on sandboxed VMs running in fast virtual memory.
They executed/open attachments and watch to see what happens - registry changes, file drops, network activity, attempts to contact known C&C servers, etc.
Anything that exhibits non-legit behavior get quarantined. FireEye have a box that does this and also crawls network shares, testing files.
Aside from whitelisting, I think it's the best defense against zero day malware. It's a little too pricy for the company I work at right now, but as more vendors add this functionality, the price will come down.
It gripped her hand gently. 'Regret is for humans,' it said.
Out of curiosity, were you dealing with enough fancy-forms-and-interactive-nonsense type PDFs that the 'just brutally rasterize it and let them eat .jpeg!' option wasn't an option, or were the attackers good enough that you didn't have a PDF renderer you could trust for the rasterizing duties?
For a long time, I thought like you, that it was my duty to ward off and protect the "children". After a while, you realize 2 things.
First, it is most likely your duty to inform and educate. Do that. Do it well, do it loud, and do it as often as you can. When someone eventually opens up one of those attachments, it will get around, and peer pressure will make everyone else gun-shy. After a user or two of mine got bit by an attachment, and I had repeatedly warned my users about these things.. I ended up with people at my desk occasionally asking..can you come look at this.. it just looks funny.. it was all about the peer pressure and not wanting to be That Guy who clicked the stupid link.
Second, and I hate to say it, this is what we do, and this is job security. You can't save em all Hasselhoff, if ya did, there would be nothing left to do..
I think you are thinking PostScript. PDF requires that all computations resolve to a well defined value based on information contained within the document (i.e. not turning complete). So then of course Adobe had to add a turing complete language back in.
I don't know if any implementations are stupid enough to implement this(at least without some very careful sanitizing); but(in addition to ramming in javascript and the ability to embed basically anything at all, thanks for nothing 'rich media annotations'), they even added: Launch Actions!
"12.6.4.5 Launch Actions
A launch action launches an application or opens or prints a document. Table 203 shows the action dictionary
entries specific to this type of action.
The optional Win, Mac, and Unix entries allow the action dictionary to include platform-specific parameters for
launching the designated application. If no such entry is present for the given platform, the F entry shall be
used instead. Table 203 shows the platform-specific launch parameters for the Windows platform. Parameters
for the Mac OS and UNIX platforms are not yet defined at the time of publication."
Your Standards Compliant Solution for executing arbitrary binaries with arbitrary parameters. No need for messy, version-sensitive, exploit code! Combine with javacript and web-interaction support to build documents that search the target's hard drive for interesting things upon being opened... Or(miracle of miracles!) build a PDF that runs the adobe update utility when you open it, you're sure to find something new every time!
There's an interesting talk from Chaos Communication Camp 2011 about making a verified PDF scanner in the Coq proof assistant: http://www.youtube.com/watch?v=CmPw7eo3nQI