Modern browsers are closing the door on Java exploits, but some threats remain

Was 2015 the year the industry finally eradicated Java exploitation? Well, not quite, but the good news is we’re getting there.

It should be no surprise that encounters with Java exploits continued to decrease significantly in the second half of 2015 — All of the most commonly encountered exploits target vulnerabilities that were addressed with security updates years ago. While Java was once the vehicle of choice for attackers, modern browser technologies have rendered such exploits largely ineffective.

This is good news for IT security teams is that they can now concentrate more resources on emerging threats like those that have been targeting Adobe Flash. Despite the positive trend, it doesn’t mean organizations can ignore the threat of Java exploits entirely. As you can see in the graph below, some of the more common Java-based threats are still out there. While they are occurring much less frequently than they were years ago, organizations still need to ensure they are protected.

The fact that these numbers continue to decline is likely due to several important changes in the way web browsers evaluate and execute Java applets. The default web browser in Windows 10 is Microsoft Edge, which does not support Java or other ActiveX plug-ins at all. This in effect eliminates the possibility of Java exploits being delivered within the browser.

Other browsers are also built to eliminate or mitigate exploits:

• As of September 1, 2015, Google Chrome stopped supporting the NPAPI plug-in architecture that many Java applets rely upon due to security concerns. Like Edge, Chrome no longer works with most Java-based plug-ins.
• Mozilla Firefox currently allows users to disable Java applets by deselecting “Enable JavaScript” under its Content tab, and has announced that it will also discontinue NPAPI support by the end of 2016.
• Internet Explorer 11 provides a mechanism to validate that a webpage is safe before allowing embedded Java applets. Further updates to Internet Explorer released in 2014 hardened the browser against Java exploitation by reducing use-after-free exploits and blocking out-of-date ActiveX controls.

Persistent threats

The fact that new browsers are flexing muscles in the security space is good news, but the bad news is that some threats still persist. The chart above shows that each of these exploits is in decline, but they are all risks that security teams should be aware of, especially where there are out-of-date Java installations:

• CVE-2012-1723. This is the most common individual Java exploit we encountered in late 2015, and one we discussed way back in 2012. It works by tricking the Java Runtime Environment (JRE) into treating one type of variable like another type. Oracle confirmed the existence of the vulnerability in June 2012, and addressed it the same month with its June 2012 Critical Patch Update. The vulnerability was observed being exploited in the wild beginning in early July 2012, and has been used in a number of exploit kits.
• CVE-2010-0840 is a JRE vulnerability that was first disclosed in March 2010 and addressed by Oracle with a security update the same month. The vulnerability was previously exploited by some versions of the Blackhole exploit kit (detected as JS/Blacole), which has been inactive in recent years.
• CVE-2012-0507 allows an unsigned Java applet to gain elevated permissions and potentially have unrestricted access to a host system outside its sandbox environment. The vulnerability is a logic error that allows attackers to run code with the privileges of the current user, which means that an attacker can use it to perform reliable exploitation on other platforms that support the JRE, including Apple Mac OS X, Linux, VMWare, and others. Oracle released a security update in February 2012 to address the issue.
• CVE-2013-0422 first appeared in January 2013 as a zero-day vulnerability. CVE-2013-0422 is a package access check vulnerability that allows an untrusted Java applet to access code in a trusted class, which then loads the attacker’s own class with elevated privileges. Oracle published a security update to address the vulnerability on January 13, 2013. For more information about CVE-2013-0422 is available here.
• In addition, Obfuscator is a generic detection for programs that have been modified by malware obfuscation, often in an attempt to avoid detection by security software. Files identified as Java/Obfuscator can represent exploits that target many different Java vulnerabilities.

For a thorough analysis on the state of malware in the latter half of 2015, take a look at our latest Security Intelligence Report. And for a high-level look at the top ten trends and stats that matter most to security professionals right now, be sure and download our 2016 Trends in Cybersecurity e-book.

from Microsoft Secure Blog Staff