Adobe's "0 Face"

As you may already know, Adobe acknowledged another public security vulnerability in their products on December 15, 2009. APSA09-07 affects all current and earlier versions of Adobe Acrobat and Reader with JavaScript enabled and is currently being exploited in the wild. There is no doubt Adobe products have been in the cross hairs of attackers over the past two years and Adobe's use of JavaScript seems to provide an easy opportunity for exploitation.

Upon reading the advisory, it was no surprise that disabling JavaScript was the mitigation. Many users in my environment do not use this functionality and it can easily be turned off via the Windows registry. The problem is it does not remain off. When opening an Adobe JavaScript enabled .pdf the user is presented with a prompt to re-enable JavaScript. To date Adobe does not provide any way to permanently disable JavaScript via the Adobe Reader preferences menu or the registry. We all know how useful warnings are for end users right? <insert self-signed ssl certificate here> But I'll save the use of a warning as a form of mitigation of badly thought up functionality for a later blog post.

<my rant>

So Adobe products are increasingly being targeted and although Adobe seems to have picked up the pace with their security stance, I have often questioned if they have enough internal resources to do anything but be reactive. Once again, a zero day leveraging JavaScript in an Adobe product is flying around and the patch for this vulnerability will not be available until January 12, 2010. In my opinion, this is unacceptable. Adobe seems to be struggling with putting out the fires and are not being preventative by fixing their code or providing systems administrators with the tools or patches they need to properly mitigate. I can personally tell you my corporate IDS and Antivirus have been lighting up like a Christmas tree (tis the season) with attacks using this exploit.

Soon after the advisory dropped, I listened to Dennis Fisher and Ryan Naraine interview Brad Arkin on the Digital Underground podcast. Brad Arkin is currently Director of Product Security and Privacy at Adobe and has held previous positions at Symantec and @stake. Now Brad seems like an intelligent guy and I applaud him for taking on such a challenge. I became annoyed while listening to the interview, however. Ryan Naraine repeatedly queried Brad during the podcast on what I have suspected for quite some time. Does Adobe have enough resources in place for dealing with the current trend of attacks targeting their products? Brad seemed to repeatedly side step the question. He attempted to explain the complexity of dealing with such vulnerabilities with such a large and diverse install base.

<disclaimer> While I may have no experience dealing with what Brad has stepped up to do, I do have a lot of experience mitigating vulnerabilities in the corporate environment and my opinions here are based on that experience. </disclaimer>

Now while I have no doubt that this is a challenge indeed, maybe Adobe needs to stop, glance around, and take a cue from the company that has the largest and most diverse install base I know of. That company would be Microsoft. While far from perfect, Microsoft seems to have made some significant advances with their security program over the last 5-6 years. When MS08-067 dropped in October 2008 (for those not familiar, that’s the vulnerability used by the Conficter variants), Microsoft did what any responsible software vendor should do. They released an Out-Of-Band patch!  So what gives Adobe?

I almost jumped out of my skin when Brad stated Adobe often needs to shift resources off of other security projects and research to handle an exploit such as this. So to answer Ryan’s question, I guess you do not have enough resources then? My point is if you have to shift all your resources to handle each and every fire and it still takes you a month to put out the fire, then you will never be preventative. Maybe I am being naive here but I don't believe so.

</my rant>

Ok so with my ranting out of the way, I did state that I thought Adobe was making improvements. One such improvement is their implementation of the JavaScript Blacklist Framework mentioned during the podcast. It is still reactive but it is at least something. Thank you to Dennis, Ryan, and Brad for bringing this to my attention. To quote Adobe’s tech note located here;

“The Adobe Reader and Acrobat JavaScript Blacklist Framework introduced in versions 9.2 and 8.1.7 provides granular control over the execution of specific JavaScript APIs. This mechanism allows selective blocking of vulnerable APIs so that you do not have to resort to disabling JavaScript altogether.”

Brad admitted during the interview that this is only effective for specific vulnerabilities and it may break legitimate uses of functionality in Adobe Acrobat and Reader. He further stated Adobe has many more improvements coming during 2010. I can only hope this includes some preventative improvements to their code base and internal resources dedicated to the current target on their back.

More can be found on using the blacklist framework to mitigate the vulnerability in APSA09-07 here.

For an entertaining and informative Adobe rant (that puts mine to shame) checkout the latest post on the Sourcefire VRT Team blog, entitled Matt's Guide to Vendor Response

Happy New Years to Everyone!

Update:

More reports of sophisticated Adobe exploits have been appearing this week. Some have little to no coverage by the AntiVirus vendors. I noted the following article describing Adobe's plans to begin testing a silent Adobe updater. Someone needs to tell Adobe an updater only works if you actually provide the update and explain to them the basics of enterprise change control.

Details of the attacks can be found here and here.

Another Update:

Adobe has release patches for the Acrobat/Reader vulnerability as well as another vulnerability in Illustrator.  The Advisories can be found here:

http://www.adobe.com/support/security/bulletins/apsb10-02.html
http://www.adobe.com/support/security/bulletins/apsb10-01.html

I also found a great ADM template for tuning Adobe Acrobat and Reader JavaScript settings on the Praetorian Prefect Blog. Again, just note that the user will be prompted with a warning when opening a .pdf containing JavaScript.

OK Last Update

The Sourcefire VRT team posted an excellent article this week on the using the Acrobat JavaScript Blacklist Framework on common exploited functions within Adobe Acrobat and Reader. An example taken from their post for Adobe Acrobat 9 would be as follows:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\9.0\FeatureLockDown\cJavaScriptPerms]"tBlackList"="Collab.getIcon|DocMedia.newPlayer|Util.printf|Spell.customDictionaryOpen|Doc.syncAnnotScan|Doc.getAnnots"

 Additionally, they provide benign Adobe Acrobat files using each of these functions to test with.

Didier Stevens also pointed out during a recent interview on PaulDotCom Security Weekly that the new version of Adobe Reader and Acrobat has changed the way it warns users that JavaScript is disabled. While not quite the administrative control I had hoped for, it is a slight improvement as it renders the .pdf regardless of the action taken by the user.

Yet Another Update on the Symantec Vulnerability

It looks like DSHIELD has picked up on an increase in probes for port 12174 associated with the Symantec Advisory covered previously on this blog here and here. In some cases of upgrading from previous versions of Symantec Corporate Antivirus to 10.1 MR8, servers are still vulnerable to this exploit. So make sure AMS and Intel File Transfer service (xfr.exe) is not running and listening on TCP Port 12174.

Update on Symantec Vulnerability

So I wanted to give everyone an update on the Symantec Antivirus vulnerability I outlined in my previous post entitled; Lessons Learned: Vulnerability and Expectations Management. It appears that the exploit code has been published to the Exploit Database and has also been added to the Metasploit Framework. If you have not read my previous article, please make note here. In some cases of upgrading from previous versions of Symantec Corporate Antivirus to 10.1 MR8, servers are still vulnerable to this exploit.

The problem is due to the fact that AMS2 does not get removed in all cases of upgrading from version 9 to 10. If the Intel File Transfer service (xfr.exe) is running and listening on TCP Port 12174 then you are still vulnerable. Disabling the service or completely uninstalling and reinstalling Symantec Antivirus were the two options given to me by support at Symantec. I use the term "support" loosely here as I'm the one that told them disabling the serviced mitigates the issue.

I have attempted to get Symantec to edit their advisory with this information without success. So make sure you verify your patches with the attached code or favorite vulnerability scanner. Tenable Nessus does have a plugin available here.