Archives

All posts for the month December, 2012

This year we’ve seen a number of 0 day Java exploits surfacing and various mitigating steps mentioned in various sites that could be taken to prevent us from being compromised. A lot of these mitigating steps vary from each other so when it comes to mitigate Java in Internet Explorer it adds doubt to which is the best mitigation steps to follow. Uninstalling Java would obviously solve the problem but that is not really an option in organisations dependant on Java.

This post describes the mitigating steps available, the tests carried out and how to bypass certain mitigations. The tests have been carried out on a fully patched Windows 7 Enterprise 32bit virtual machine with Internet Explorer 8 and a vulnerable version of Java.

Prevent loading of applet in IE’s “Internet Zone”
This setting disables the loading of Java applets from the Internet zone. There are different keys representing different security zones [3] and the Internet zone has a value of 3.

HKEY_CURRENT_USER (HKCU) entry would take priority first. So if disabled in HKEY_LOCAL_MACHINE (HKLM) but enabled in HKCU then you will still be exploited so it is best just to apply the change in HKCU. Any external site attempting to use an applet tag will now not load the applet and a notification bar will be displayed.

This mitigation would only protect from applet tag examples below. With other techniques this mitigation is ineffective.

This mitigation only stops exploits using the applet tag, cannot be managed by Internet Explorer zones and any new Java update means you’ll need to update the registry again.

Invoking Java classids via OBJECT tag
Internet Explorer can use the classid attribute OBJECT tag to load Java. Hundreds of Java classids gets registered when Java is installed. One classid is particularly dangerous as it works transparently from the Internet zone without any notification bars or alerts and has been used in actual exploits. The reason being is that this classid gets added in the preapproved list.

This classid calls the latest installed version of Java Plug-in installed on the machine. Whats interesting is that this classid is already added in Windows 7 preapproved registy key without even Java being installed. To mitigate this classid needs to be killbitted

The hundreds of other classids are mainly for backwards compatibility. So if an older specific version of Java is installed, those can be called using a specific classid, in the example below its calling Java 7 update 7

The way the classid versions is worked out is in say CAFEEFAC-xxxx-yyyy-zzzz-ABCDEFFEDCBA, “xxxx”, “yyyy”, and “zzzz” are four-digit numbers to identify the specific version of Java Plug-in to be used. In references [1][2] only a handful of classid’s listed below but actually when Java gets installed it installs hundreds of classids. Click here to see all the CAFEEFAC- classid’s registered on a Java 7 update 4 installation. In these references just killbitting these classids does not make sense as invoking any other classid will give the same two prompts as these ones. (screenshots given further down in the Java Web Start ActiveX control section). So if you are thinking of killbitting these classids then follow Cert’s recommendation [4] as it kills all classids upto a certain version. A Java update will register newer classids each time so if killbitting these is an option you prefer then you’ll need to keep uptodate.

These classid’s are the only ones mentioned for Java version 7 and upto update 6.

Loading Java via the EMBED tag
Java can also be exploited in Internet Explorer using the EMBED tag. Here applet mitigations is ineffective but killbitting/disabling the ActiveX control 8AD9C840-044E-11D1-B3E9-00805F499D93 as mentioned in previous section mitigates it.

Here the the mimetype “application/x-java-applet” points back to classid 8AD9C840-044E-11D1-B3E9-00805F499D93

Prevent automatically opening JNLP files via APPLET
Java Network Launch Protocol (JNLP) could also be used for launching applets directly from JNLP files. To launch an applet from a JNLP file the “jnlp_href” parameter would need to be used in the applet tag. This could be used in a transparent driveby attack too.

When calling the jnlp file via the html file the jnlp file can be any extension so say in the above code mycalc.jnlp could be called mycalc.txt. Since this uses the applet tag the above mitigation on the applet would mitigate this threat.

Double-clicking on a JNLP file
Even with all the browser mitigations in place it doesnt stop an attacker to email a jnlp file to the victim. Just by double-clicking the attachment would compromise the machine.

Prevent automatically opening JNLP files via mimetype association
Using Java Web Start can be used to open a JNLP file. By default JNLP files open without any interaction from the user. For this to be exploited the web server would have to be configured with the .jnlp file extension to the mimetype “application/x-java-jnlp-file”. Then simply visiting a link say http://192.168.1.3/mycalc.jnlp would compromise your box.

Java Deployment Toolkit ActiveX Controls
This Java Deployment Toolkit classid CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA was exploited in 2010 (CVE-2010-1423). On a fully patched Windows 7 machine this has already been killbitted without even Java being installed and points to an alternate classid CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA. This classid has been killbitted in Cert’s mitigation so its recommended to keep this one killbitted too.

Renaming the “jp2iexp.dll” file would also temporarily mitigate the APPLET and OBJECT tag attack vectors but not the others mentioned. A Java update installation would drop the file back though so bear that in mind.

Other classids that would need some interaction are also best to be killbitted

Using the latest classids for the Java version would require the user to acknowledge two warnings but once accepted thereafter no warning would be given so killbitting the CAFAEFAC- classids might be worth thinking about in your managed environment. Finally JNLP files could be sent via email so you might want to take a proactive step in blocking jnlp file attachments on your mail relays.

Latest Java release
Following the release of Java 7 update 10 last week I thought I’d do a quick check on its new security features. There is now an updated security tab giving the user now more control on what to do.

Changing the security levels makes changes to the file deployment.properties in location

C:\Users\user1\AppData\LocalLow\Sun\Java\Deployment

By default its set to medium but if changed to low the entry deployment.security.level=LOW is added to the file. Since this is in a low integrity folder this could be changed to LOW settings by a low privileged user.

Un-checking the “Enable Java content in the browser” is quite drastic step as it deletes all classids, mimetypes, jnlp file association, etc. The command that gets run when un-checking and applying is

"C:\PROGRA~1\Java\jre7\bin\ssvagent.exe" -disablewebjava

This feature would most definitely protect from browser based attacks but also most likely break all your internal apps so not something to implement without thorough testing in an enterprise environment. For home users it gives the flexibility to enable and disable when needed say if you want to do a vulnerability scan which uses Java.

Conclusion
This research has shown that if you dont need Java best to just to uninstall it. If there is a requirement then upgrade to Java 7u10 and uncheck the Java content in the browser settings. Finally follow only Certs advisory [4] or the very least make the few mitigating changes mentioned in the “Preventing compromise” section regardless if you have “Java Content in the browser” enabled or disabled.