Not sure if anyone saw this bit of news recently where a report put out by ScanSafe indicates that PDF’s accounted for 80% of exploits in the 4th quarter of 2009. I support both FCS our antivirus product and I also do Incident Response work. As part of our IR work we do semi-forensics shall we say 🙂 we do not do forensics as that would be something that is admissible in a court of law and our toolset isn’t we modify last access timestamps don’t keep a chain of custody etc. So as part of this dual hat role that our group currently plays when we see a customer that keeps submitting new samples repeatedly and raising the alert to us that our product is not cutting it with regards to detection of malware we like to push into the why/how this customer keeps finding all these new malwares.
So as an AV vendor do we have some blame to take here 🙂 absolutely we missed some new variant. In a perfect world either IE8 with url reputation would have seen it as bad or our AV would have detected the malicious PDF or the .exes/services it created. Unfortunately all of these are reactive prevention mechanisms that are extremely reliant on previous signatures to detect them or being close matches to heuristic patterns.
On the other hand though when you are browsing the Internet with Adobe Reader that is any version lower than the latest you’re pretty much asking to try out new variants of malware. So if I’m going to take some blame then someone else needs to as well guessing both Adobe for lack of a patch management enterprise solution and the user of their products for not managing the state of this application in their environment.
So blame game aside lets move beyond this we know we have a problem here so what do we do to fix it.
- Long Term there needs to be a patch management solution in place that keeps all clients up to date with all installed products. Have seen some interesting things around Shavlik SCUPdates for SCCM as well as Secunia CS product they are creating to integrate with WSUS. Also posted here it seems that Adobe is currently working with us to integrate their updates to their products into WSUS and SCCM which would be great, would be even better if we had this for JRE and some other products that are used widely for exploits.
The latter of those 2 is what I focused on for a while trying to find some items to help in the short term mitigate while you work on getting a patching solution in place. I have an attached GPO at the end of this that makes most of these simple. You create a new GPO and then import settings from the backup via GPMC. The following is a list of what is included with this:
- 2 Reg binary keys that are hacked manually into the .pol files of the GPO as adm syntax does not allow reg binaries in hex. The keys are HKCU\Software\Classes\AcroExch.Document.7\EditFlags set to 0’s as well as HKCU\Software\Classes\AcroPDF.PDF.1\EditFlags set to 0 as well. These will force IE to give a prompt every time a .pdf is encountered for Open/Save. This seems to work for Reader 6-9.
- Registry keys in the User section Administrative Templates for the following
- Disable Browser check on startup for Reader 9
- Disable Browser integration for Reader 9 (make’s it open in separate window not within IE this only seems to work via reg key for Reader 9)
- Disable Fast Web View for Reader 9
- Disable Javaascript for Readers 7-9
- Registry key under Computer section Administrative Templates for the following
- Disable user from re-enabling Browser Integration in Reader 9
- Software Restriction Policies under the computer section for the following
- Path Rules for Reader 6-8 these are all set to Unrestricted by default if you change them to Restricted it will block any builds of those versions of Adobe Reader from running on your XP and higher systems that you apply this to.
- Hash rules for Adobe Reader 9 builds 184.108.40.2062, 220.127.116.11, 18.104.22.168 This would allow you to block any but the currently latest version of Reader from running in the 9.x series.
I didn’t do one on managing Active X controls however this would be fairly simple as well to restrict the CSLID of the Active X control for reader. Unfortunately however Adobe has used the same CSLID since the beginning of time it seems for the Adobe Reader controls so you can’t killbit it or restrict it without restricting it for every version of Adobe including the latest patched ones so that is something you would need to evaluate in your environment.
Another caveat is that you can’t disable the browser integration just with reg keys for versions of reader less than 9. The reg keys are there in some cases however just setting them only changes the setting in the preferences GUI but not the actual behavior of the program which appears to do a lot more than just those reg keys when you throw it under procmon while making that change (it runs msiexec reconfiguring the program I eventually just gave up on it 🙁 )
So here is the GPO
You will need to create a new GPO in AD and then use the GPMC to import settings from a backup and point to the folder where you extract this .zip.