Protecting yourself from new Java zero-day exploits

EDIT 8/30/12 15:16 – An update has been released that corrects at least some of the vulnerabilities being exploited in zero-day attacks. The auto-update routine in Java on my test workstation was not picking up that an update was available. I manually downloaded the Java 7 Update 7 installer here and ran the installation. When testing the Metasploit version of the exploit, exploitation before the update was successful however subsequent exploitation was unsuccessful. Screenshots below:

Successful exploitation of 1.7 Update 6 originally installed; you can see where a directory listing was successful on the compromised PC (filenames blurred out):

Updated version of Java installed on target workstation:

Exploitation attempt after update to Version 7 Update 7 (no session is successful):

It appears that an update has been released that fixes at least one of the two bugs; At this point manual updates may be required. Abundance of caution should be taken until documentation surfaces as to the extent of the patch released.

EDIT 8/30/12 14:48 – reports of a patch have surfaced; will follow up with confirmation shortly.


Original article –

Last week, two zero-day (unpatched) vulnerabilities for Java 7 were discovered by security researchers observing a malware infection believed to have originated from China. Since that time, exploits for the vulnerabilities have been incorporated into popular malware kits, such as Blackhole, and the Metasploit exploitation framework. Active phishing scams have been noted in the wild targeting users worldwide. Sorry fanboys, but the exploit is multiplatform and affects not only Windows, but also Mac OSX (and Linux). Java version 6 is REPORTEDLY not vulnerable, however some security researchers have questioned whether this is the case. Exploit code seen thus far appears to target version 7 only.

Zero-day exploits are usually closely held by their developers – disclosure generally means that the vulnerability will soon be patched and greatly reduce the effectiveness of the exploit in the wild. It is pretty unusual that an exploit of this nature leaks out into the mainstream. To make matters worse, rumors have surfaced that Oracle has been aware of the presence of these vulnerabilities for months and failed to include fixes in the most recent June update – it is unknown how soon a patch will be released. Oracle is typically slow to patch Java with updates typically only being released 3 times per year – unless an out-of-band patch is released, it could be mid-October before a patch is released.

According to Immunity developer Esteban Guillardoy, “The beauty of this bug class is that it provides 100 percent reliability and is multiplatform. Hence this will shortly become the penetration test Swiss knife for the next couple of years (as did its older brother CVE-2008-5353)”.

So now the question at hand…how do I protect myself?

We discussed mitigation tactics for Java (and other) exploits in a previous blog post on patch management. Unfortunately, this is a zero-day so patch management techniques do not apply – there is currently only one way to guarantee that you will not fall victim to this exploit, and it is not a pretty one for many users – uninstall or disable Java. This is easier said than done since many websites and browser-based business applications require Java to function properly.

Firefox users have it easy – there are addons available for that put toggle buttons in the statusbar allowing users to quickly enable / disable Java (as well as Flash, Silverlight, etc). I personally use Firefox and use the QuickJava and NoScript addons to restrict Java code from running unless I’m on a trusted site that requires Java.

Internet Explorer and Chrome users have to jump through a few more hoops (it’s actually downright nasty in IE since simply disabling the plugin does not completely mitigate the vulnerability. Detailed mitigation techniques for all browsers can be found here.

As an alternative, users running Java 7 may downgrade to version 6, which is reportedly not vulnerable to the zero-day exploits in question. As previously stated, some security researchers have questioned whether this is actually the case, however current active exploits appear to target only version 7. Various Java versions may be downloaded here.

Enterprise network administrators may also consider enabling egress URL whitelisting on perimeter firewalls / content filters to restrict users from accessing any internet websites that are not specifically allowed. This may not be a viable option for many organizations depending upon business requirements for internet usage or technological limitations in their security environment.