The word “Adobe” conjures up a number of meanings here.  When we get an email that mentions just “Adobe,” we fill in the blank with one of the following:

• Adobe the Company
• Adobe Acrobat
• Adobe Acrobat Reader
• Etc.

This invariably leads to confusion.

A similar confusion exists surrounding the recently reported Google incident (http://isc.sans.org/diary.html?storyid=7969) especially when Adobe released a similarly worded announcement: http://blogs.adobe.com/conversations/2010/01/adobe_investigates_corporate_n.html
This led some folks (including me) to the conjecture that the attack involved the use of a malicious PDF file.  I’ve seen examples where this group used malicious PDFs, but nobody provided an example of the PDF file used in THIS attack.  Adobe’s (the company) ASSET security team released additional details yesterday (http://blogs.adobe.com/asset/2010/01/further_details_regarding_atta.html) where they assert that Adobe Acrobat Reader was not involved in the incident, that instead it was an IE vulnerability detailed here: http://siblog.mcafee.com/cto/operation-%E2%80%9Caurora%E2%80%9D-hit-google-others/

So, to recap: Adobe (the company) was attacked, but it wasn’t by leveraging an Adobe product.

So let’s look instead at how their products ARE being used to compromise systems…

The folks over at FireEye have a nice blog entry on PDF malware obfuscation and how it’s being used by the Neosploit exploit kit to distribute Mebroot: http://blog.fireeye.com/research/2010/01/pdf-obfuscation.html

Fortunately CVE-2009-4324 has been patched.

A little unsolicited feature request from Adobe for Acrobat Reader: take a gander at that little no-script add-on to Firefox.  I understand that when I download an interactive PDF-form that it’s going to need some javascript to run.  I just want to have an opportunity to click “no” when I get an unexpected PDF while browsing blogs.
 

Kevin Liston

kliston@isc.sans.org