The majority of enterprises likely have more than one version of Java installed on endpoints, and many of them still are running outdated versions of Java 6, according to Bit9 researchers.
In an analysis of “approximately one million endpoints” across “several hundred deployments,” Bit9 researchers found that 42 percent of endpoints had more than two versions of Java installed at the same time, according to the report released Thursday. This happens because running the installer creates a new instance of Java on the system without removing the older versions, Harry Svedlove, CTO of Bit9, told SecurityWeek. Even the recent installers remove only the minor updates within the same version, so version 6 installers would not touch version 5 installations, for example.
“IT administrators have been lied to,” Svedlove said. “They’ve been told to apply patches to stay safe,” but there was no mention of the fact that the software didn’t remove older versions of itself, he noted.
For example, if the user has Java version 6 Update 13 installed and tries to update, the process will attempt to remove Update 13 and install the latest version, in this case, Java 7 Update 25, the report said. However, the same process would not remove Java version 5 update 22 if that version also had been installed previously, according to the report. At the end of the update, the user would have both versions 5 and 7 installed on the same machine.
“It is perhaps not well known outside the security research community that malicious Java code can target outdated instances of Java even after the most recent version of Java has been installed on an endpoint,” the report found.
People don’t expect that a malicious Word document would open in Word 97 instead of Word 2007, if that was installed, or that clicking on a PDF file will open an older version of Adobe Reader rather than the most recent version installed, Svedlove said. Yet that is exactly what happens with Java.
The malicious code can specify which version of Java to use, and attackers can target any of the vulnerabilities in the older software. There is no need to bother with finding zero-days or uncovering new vulnerabilities in the latest version of the software.
“It seems likely that older endpoints carry more and older versions of Java,” the report said.
Each endpoint had an average of 1.6 versions of Java installed, and the average organization had 51 distinct versions of Java running on its systems, Svedlove said. Approximately 20 percent of endpoints analyzed had three or more versions installed. Bit9 also found that 5 percent organizations had 100 or more distinct Java versions running in their environment.
Nearly 93 percent of organizations were running a version of Java that was at least five years old, and 51 percent had a version between five and ten years old, according to Bit9. Only 7 percent of organizations do not have Java versions that were five years or older installed.
There is clearly a patching problem, that organizations still have “significantly out-of-date” versions running in their environments. Furthermore, at the time of the analysis, the most up-to-date version of Java was version 7 update 21. Only 3 percent of all endpoints, or a mere 0.26 percent of organizations, had this version installed.
Of the older versions left behind on the computers, most were Java 6, Svedlove said. Java 6 officially reached end of life earlier this year. Bit9 researchers analyzed Common Vulnerability Scoring System values for Java-related vulnerabilities and determined that Java 6 was the most vulnerable version of Java. Considering Java 6 is present on 82 percent of the systems, it is no surprise that attackers are increasingly targeting Java, Bit9 said.
While security issues with Java has been a matter of concern for the past few years, a number of critical vulnerabilities discovered in Java and high-profile attacks earlier this year have made the problem much more pressing. In fact, last year Java surpassed Adobe Reader as the most exploited endpoint software in real world attacks.
Java is so ubiquitous that it is virtually on every end-user system, even though fewer and fewer Websites and Web applications actually require Java to operate properly.
A user may have the most recent version of Java installed on the machine, but still be vulnerable to attack because attackers can use exploit kits and off-the-shelf malware to target one or two vulnerabilities present in the older versions of the technology still installed on the system.
Java is the “single most important security problem facing today’s enterprises,” Svedlove said.
Many in the security industry urge completely removing Java from all endpoints, arguing it is no longer necessary. This option is often difficult to implement in practice. It may be difficult for enterprises to do a wholesale removal, and it is “often difficult for organizations to fully assess the impact of removing Java in their environment,” the report said.
Svedlove argued that organizations need to do a thorough audit and understand which systems have Java installed, and identify what versions are running. If there is no business reason to have an older version running (because of a legacy application that requires the older version), then it should be removed. An audit is a good first step towards identifying exactly who needs Java and who doesn’t.
Regular audits will also flag unauthorized installations.
Svedlove was careful to clarify that the report focuses on the problems of using Java as a client-side Web technology. Products containing their own embedded versions of Java are generally not accessible to the browser and do not expose the user to the same level of risk, he said.
Many of the deployments analyzed by Bit9 comprised mostly of servers, point-of-sale (POS) terminals, and other fixed-function endpoints which never have Java installed. With that in mind, it’s likely that the average number of versions running in the organization would be “quite likely much higher” if looking at only desktop environments, the report said.
Related Reading: How Can We Put an End to the Mass Java Exploit Era?
