Test to see if you're vulnerable.
Java has a long history of 0-day vulnerabilities being actively exploited. Exploits are usually drive-by attacks: users get infected by navigating to hijacked websites where an invisible Java applet drops a malicious executable on the user's machine. The very popular, Blackhole exploit kit includes numerous Java exploits.
In 2010, we reported a 300% increase of malicious JAR (Java archive) files. Recently, in March 2012, Java made the news due to the Flashback Trojan, a piece malware targeting an older Java version that shipped with Mac OS X. As can be seen, Java is constantly under attack.
Update: new Java version available
Oracle has released java 1.7.7 and 1.6.35 to fix the vulnerability. You can update your java version from Java.com.
We have updated our Java test page to take the new versions into account.
Are you vulnerable?
The latest iteration of Java is version 1.7 revision 6. This is now the default version on Windows. Mac OS X still uses Java 1.6 (latest version: 1.6.33). Java 1.6.33 is NOT vulnerable to the latest 0-day exploit. However, I would not suggest that anybody downgrade from Java 1.7 to Java 1.6 as it is not yet known if version 1.6 is vulnerable to other flaws fixed in 1.7.
One annoying fact with Java is that new versions are installed on top of each other. As such, you are likely to have multiple versions of Java installed on your system. Internet Explorer may not even be using the latest version of Java that you have installed.
We have created a new page to list all of the versions of Java installed on your computer. You can test your browser here.
Disable Java
To be on the safe side, you can disable Java in your browser to prevent malicious applets from running.
Firefox
Go to Tools - Add-ons - Plugins
Look for Java Deployment Toolkit and/or Java Platform SE. Disable them all.
 |
| Java disabled in Firefox |
Chrome
Go to Wrench - Settings and Show advanced settings... - Privacy and Content settings - Plug-ins - Disable individual plug-ins... - Java - disable. It is quite difficult to find!
 |
| Java enabled in Chrome |
Internet Explorer
Go to Tools - Manage Add-ons. Disable Java(tm) Plug-in SSV Helper and Java(tm) Plug-in 2 SSV Helper.
 |
| Java disabled in Internet Explorer 9 |
Test it
Now go to our Java test page (updated) to ensure that Java has indeed been disabled in your browser.
Click to Play
If you need Java occasionally, you can enable it on-demand with Click to Play. I described Click to Play, a way to manually enable plugins only on visible content, in a previous post. This feature is only available in Firefox, Chrome and Opera.
Firefox also offers several browser extensions to easily enable/disable java with one click. I personally like Quick Java.
Take this opportunity to check all the plugins running in your browser and disable the plugins that you do not really need. Don't give the bad guys an attack surface that's any larger than it needs to be!
Posts
11 comments:
http://zulu.zscaler.com/research/java_version.html
First of all thanks for this free test. I have only one problem. I am an Opera user and have already disabled the java plug-in in the browser. Nevertheless this test page here still detects my Java version number and says that the vulnerability still persists.
Oracle's own Java test page says that my plug-in is disabled just as a number of other test sites. How to explain this? Do I have to worry?
Some want to write up a how-to downgrade Java 7 to 6....
It's not as easy as it sounds....
Thanks for the free test ;-) come back clean (zero )
We found that disabling the Java Plug-in in IE was more complicated than just using the Manage Add-ons. Furthermore disabling the the "SSV" add-ons doesn't disable the Java Plug-in. More info here: http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE
I have a updated the test page to differentiate between Java being installed, and Java being enabled in the browser.
Art: you're right, it looks like the add-ons disable the bridge JavaScript<->Java only. JavaScrit detects that Java is disabled, but applets are actually executed. I have updated the post with the link you provided. Thank you
The vulnerable version of JRE should be preinstalled and if target host had been compromised by running a malicious java applet then there should be evidence of compromise right? There is need for some kind of payload to be executed on client side: 'C:\WINDOWS\system32\calc.exe' for example.
The vulnerable version of JRE should be preinstalled and if target host had been compromised by running a malicious java applet then there should be evidence of compromise right? There is need for some kind of payload to be executed on client side: 'C:\WINDOWS\system32\calc.exe' for example.
It would be awesome if Zscaler had a report to show which users/websites are loading Java applets. That report could then in turn, be used to create a whitelist of sites to allow Java either directly inside of Zscaler (best since browser doesn't matter then) or through Group Policy (difficult if multiple browsers are in use).
To follow up on my previous comment, we've since found our advice to disable Java in IE still came up short. There's an update now (Java 7u7), and we've updated our advice at http://www.kb.cert.org/vuls/id/636312#disable_java_in_IE
Oddly, Java 7 Update 11 was JUST applied to my machine via manual means, and your page still states it's vulnerable. The version shows as 1.7.0 on your page, but shows as 1.7.0_11 in my machine... is there an update to this???
Post a Comment