Java has been a very hot topic for security managers this year due to a steady stream of 0-day Java vulnerabilities that have been disclosed, with many of them being exploited in the wild. However, the challenges of Java-based threats go deeper than your average 0-day vulnerability, and these challenges will likely affect your approach to controlling them.
A Broad Attack Surface
One of the key advantages of Java lies in its ability to work across platforms. In general, if you develop your application or applet in Java, it should work across any number of operating systems or browsers that support Java so that you don’t have to rewrite your application for each operating system. Of course, such broad support also means that a vulnerability in Java has the potential to apply across platforms as well.
Exploit-Facing Signatures (A Slight Return)
Unfortunately, the challenges of Java exploits are not simply limited to a large attack surface. Java exploits pose challenges to IPS solutions that are potentially even more insidious.
At the heart of the problem is the difference between vulnerability-facing IPS signatures versus exploit-facing signatures. An exploit-facing signature is a simple signature that directly matches a specific exploit payload. However, there are often multiple ways that a given vulnerability can be exploited. As a result, more sophisticated IPS vendors began to write signatures that targeted the underlying vulnerability as opposed to each individual, specific exploit. Thus, these “vulnerability-facing” signatures would provide protection against many variants of an attack and have proven to be the far more effective approach for modern-day IPS products.
The problem is that the nature of Java and the JRE make it very difficult to write vulnerability-facing signatures. Java applets are typically delivered via .JAR files, which contain java class files, which are then run in the Java Runtime Environment. This introduces a subtle but very important shift. Unlike a traditional attack where the exploit is passed directly over the network, the java exploit is carried within the java class file. Instead of seeing the actual attack, security solutions see “the code of the code” so to speak. And there are a very large number of ways that the actual malicious payload can be obfuscated in the class file. The class file can be changed, and the payload itself can be re-encoded or reflected.
In short, this means an attacker can create many variants of JAR files and java class files that look unique but carry the same underlying exploit. This is akin to how attackers can simply re-encode malware in order to avoid traditional antivirus signatures.
Blending Security Controls
Dealing with Java vulnerabilities requires a layered approach. The first step is for an organization to understand precisely where and why Java is needed. Based on the rate of newly discovered vulnerabilities, security teams should assume that Java is and will continue to be vulnerable. When and where possible, Java should be disabled in order to reduce the attack surface. This is especially true of internet-facing systems. In situations where Java is absolutely required, users should consider moving to a two-browser approach, with one browser that is used to access internal Java-based applications, and another browser with Java disabled for browsing the Internet.
Further, security should enforce strict control over JAR files and java class files. In many cases these files can be blocked outright, or only allowed from very specific trusted sources. Its also important to know that JAR files are essentially specialized ZIP files, so controls should be configured to inspect within ZIP files for java class files as well.
In terms of prevention, teams should aggressively maintain their IPS solutions and push their IPS in terms of coverage for newly identified vulnerabilities. Additionally, teams should pursue virtualized analysis of unknown files to identify threats that may avoid the IPS.
These are a few simple suggestions, but as with any type of vulnerability, the key is to weigh the risk of a technology against the reward for the enterprise. For many enterprises the rewards of Java have considerably diminished over the years, while the risks are growing exponentially. So many organizations will need to take a long, hard look at Java and answer for themselves if it’s worth it.
Related: Unpatched Java Versions Remain Widely Used: Report
Related: Oracle Talks Java Security, Pledges More Outreach to Java Community