NCA Security & Technology Insight: The Unique Challenges of Controlling Java Exploits

By Wade Williamson

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.

This means there is a vast, sprawling attack surface of systems that could be impacted and this leads to lots of work for IT security. Updating a few IIS webservers is child’s play compared to updating the Java Runtime Environment (JRE) of every java-enabled laptop, server and computing device, meaning that updating vulnerable systems is slow, laborious and prone to missing a device.

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. It’s 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.

Wade Williamson is a Senior Security Analyst at Palo Alto Networks. He has extensive industry experience in intrusion prevention, secure mobility, and both wired and wireless networking.

Contact your NCA trusted advisor at or 1.800.604.6536 to learn more.


Strategic Link is the NWCUA’s wholly-owned service corporation, using the power of aggregation to provide the Association’s member credit unions with exclusive high-quality, competitively-priced products and discounted services. Contact Director of Strategic Partnerships Craig Reed today to find out how Strategic Link can help your credit union save money while meeting its goals in 2013 and beyond: 206.340.4789,

Posted in Advocacy News, Around the NW, CUNA, NWCUA.