Java was originally released with the slogan "write once, run anywhere," which was intended to underscore its cross-platform capabilities. Over time, Java has become ubiquitous on endpoints, so "run anywhere" can be interpreted as referring to its ubiquity.
Even as fewer websites and web applications require Java in order to operate properly, the technology is pervasive on virtually every end-user system. For this reason, Java has also become a platform that is highly vulnerable to attack.
In 2013, Bit9's research team analysed Java deployment statistics on approximately one million endpoints at hundreds of enterprises worldwide.
Highlights of the findings included:
- The average organisation had more than 50 distinct versions of Java. Five percent of organisations have more than 100 versions of Java installed. Typically, organisations that have fewer total versions of Java within their environment are those with more fixed-function devices, which usually do not have any version of Java installed.
- Most endpoints had numerous iterations of Java installed, in part because the Java installation and update process often does not remove old versions.
- Attackers can determine what versions of Java an enterprise is running and target the oldest, most vulnerable versions.
- The most popular version of Java running on endpoints at the time of Bit9's analysis was version 6 update 20, which was present on nine percent of all systems and has 96 known vulnerabilities of the highest severity.
- Less than one percent of enterprises were running the latest version of Java.
Organisations continue to be behind the curve on patching Java. Typically, it takes an organisation between three and nine months to apply Java patches due to the extensive quality assurance testing they need to conduct before applying each patch.
Were it not for the fact that hackers have been paying close attention to Java vulnerabilities, this would be less of an issue. Earlier in 2013, Java vulnerabilities prompted US-CERT to encourage the public to disable Java unless it is necessary.
However, disabling Java is not as easy for some organisations as it sounds. It's similar to the fact that it's easy for home users to upgrade their Windows OS overnight, but it often takes corporations years to plan for and implement such a move.
A history of Java-related attacks
There are many examples of attacks involving Java that a simple web search will show. The following are some attacks that have unique and interesting aspects:
In early 2012, Trojan malware was discovered infecting Macs and creating a botnet of Mac-based endpoints. This malware was notable for being the largest scale threat to the Mac platform to that date, according to Macworld.
The relative ease of creating malware in Java, and the ability to construct it with only a modest amount of platform-specific code, may have aided the attackers.
Another example of threats related to Java in the wild was identified in May 2013. This attack targeted a zero-day vulnerability in Internet Explorer. However, the first action taken by the malicious code, according to AlienVault Labs' analysis, was to enumerate all of the Java versions on the affected endpoint.
Quite likely this reconnaissance step was intended to ensure the ability to compromise the host again in the future if, for example, the zero-day vulnerability was patched via the Windows update mechanism.
It also is interesting to note that the attackers apparently used code directly taken from the Java Deployment Toolkit.
How to reduce Java-related risks
So, what can be done to reduce the likelihood of a Java-related attack?
First, evaluate whether Java is necessary for your organisation. Many in the security community urge the widespread and complete removal of Java from all endpoints. This option is often difficult to implement in practice, however, because tools for managing Java in the enterprise are lacking.
If removal is chosen, develop a plan. Consider tools that can block execution of software based on name or hash on the endpoint as a quick first step towards the eventual goal of removal.
Use software management tools to remove instances of Java. In addition, close the loop – that is, audit the software in your enterprise to confirm Java's removal. Finally, consider using network security solutions such as those with layer 7 visibility to look for evidence of browser-based Java.
Monitor for unexpected installation and use of Java in the environment.
When using NIST data to find vulnerability information, keep in mind that software and vulnerabilities may not always be recorded in a consistent manner. For example, some vulnerabilities are reported under the product "Java," while others (most in fact) are reported under the product "JRE."
Conclusion
For the past 15 years or so, IT administrators have been under the misconception that updating Java would address its security issues. They have been told that to improve security, they should continuously and aggressively install Java updates on all of their endpoints.
Unfortunately, installing is not the same as updating. As a result, most organisations have multiple versions of Java on their endpoints, including some that were released at the same time as Windows 95.
Not only is Java widely installed in most enterprises, in most instances it is highly vulnerable. Java continues to be a required technology for many companies, but its ubiquity seems to be out of proportion with its current business use cases.
Bit9's data seems to show the reasons behind Java's new favoured status among attackers. Many enterprises have so far been slow to respond appropriately to this trend, despite evidence that doing so would, for many, substantially reduce their exposure to today's most common successful attacks.
Recent high-profile attacks continue to demonstrate that enterprises should view Java as a major security risk.
Enterprises can benefit from better characterising and understanding the applications running on the endpoints in their environment, so they can evaluate the risks to those endpoints and more effectively prioritise remediation efforts. Moving forward, real-time visibility and protection for endpoints and servers will be essential.
- Harry Sverdlove, Bit9′s Chief Technology Officer, draws from nearly two decades of application design and analysis with industry-leading IT enterprises to add a new layer of technical expertise and strategic vision to Bit9′s Trust-based Security Platform.
