|
These PDF exploits have been on-going in various guises for quite a while. Gumblar was popular in early 2009:
gumblar-cn-exploit "When you inadvertently load an infected page, it redirects you to the gumblar webpage, and it pushes a pdf file to your computer."Redirection to malware web pages continues with use of SQL injection on compromised web sites, and through contaminated links on Search Engine Pages. Symantec has identified PDF exploits as Trojan.PiDieF: The Trojan.Pidief family is a Trojan horse that exploits Adobe Reader and Acrobat vulnerabilities in order to install malware onto the compromised computer. The PDF exploits have at least four requirements to meet in order to be successful. First Requirement: Javascript must be enabled. Several different codes have been noted: 
With javascript configured per site in the browser, this means that if you are redirected -- say, from Google -- to a malicious site as in the current spate of attacks, the exploit doesn't even start, since that site will not have scripting enabled. The user gets a blank screen - the exploit fails. Here, I've disabled Javascript in Firefox and so, get a blank screen: 
(From here, I've enabled Javascript so as to see the rest of the steps of the exploit). Second Requirement: the PDF file must be able to load in the browser where the exploit code in the file can execute. This is easily prevented by several means, including disabling Plugins, or unchecking the option in the Reader Preferences to display PDF in the browser window. The exploit will fail at this point, and the browser will prompt for action: 
Third Requirement: If the file does display in the browser window and the Reader is vulnerable to the exploit, code in the PDF file will execute to have the Reader call out to download malware. This also pertains to opening a PDF file directly in an email attachment, or on the Web: 
At this point, a firewall which monitors outbound connections will alert to an unauthorized application, Acrobat Reader, and the exploit fails: 
Fourth Requirement: if the exploit gets this far, the malware attempts to download, and any product with execution protection will intervene to prevent an unauthorized executable file from downloading/installing, and the exploit fails: 
CONCLUSION This should be an easy exploit to prevent, for if something intervenes at any of the four steps, then the exploit fails! ADDENDUM The use of a file as the trigger to download malware is nothing new. As early as 2004, the .ani (animated cursor) file was used, and in late 2005, the .wmf (Windows Media File) was very successful. Both used this code: 
It really doesn't matter how the download is triggered: the basic prevention is the same. Some AV products now detect malicious PDF files and the payload, but, being signature-based, are prone to be fooled. |
