Lagging Updates Compound Java Risks

Most Windows-based devices are running Java 6. Oracle is no longer releasing patches for this version of the software, which makes machines running it vulnerable to security risks.

Protecting popular software like Java against security vulnerabilities requires three steps. First, exploits must be discovered. Second, the vendor needs to develop effective patches. Third, end users or administrators need to apply the patches to client machines.
The longer it takes for this cycle to play out, the more exposed and vulnerable it leaves users. In the case of Java, the cycle is taking too long.
That is the finding in a recent report published by Websense Security Labs, which found that over 80 percent of enterprise browsers have enabled Java clients but only 19 percent of Windows-based machines are running the latest version of Java 7. Most are running Java 6, which is no longer being patched and vulnerable to significant exploits.

Zero-day Risks

Zero-day exploits are among the most dangerous. When a malicious attacker discovers and leverages a security flaw before it has become known to the software developer, this zero-day attack can impact everyone using the software. Users remain vulnerable until a patch is developed, released and applied --- meaning that a zero-day exploit can remain dangerous for a length of time that can be counted in days, years or even forever.

For example, Microsoft recently warned that users who continue using Windows XP beyond April 8, 2014 – the OS’ end-of-support deadline – will be vulnerable to "permanent" zero-day exploits. After that date, Windows XP will never receive security patches even for newly discovered exploits.
Likewise, Java 6 was "retired" by vendor Oracle in February of this year. Its last public patch was released in April. Yet, zero-day vulnerabilities like CVE-2013-2463 and CVE-2013-2473 are out in the wild. Which means exactly what?

Crime Kits and Ransomware

They say that crime doesn’t pay, but unfortunately in the world of online malware, it actually does. Or, at least, it can. "Kits," which can be purchased or rented by aspiring evildoers and provide a user-friendly interface to launching attacks, are the latest evolution in malware.
A crime kit such as Neutrino not only gives an attacker point-and-click access to finding targets and deploying attacks, it even lets them track their success across infected machines. Attackers can access a variety of attack tools from remote screen viewers to keyloggers.
Increasingly attackers are using crime kits to install so-called "ransomware" such as Reveton. Ransomware is a type of malware which attempts to extort payment from the victim. For example, the Reveton malware claims to be a product of law enforcement accusing the target of having broken the law and requiring them to pay a “fine” to restore access to their machine.
Kits like Neutrino are regularly updated with zero-day exploits to enhance their ability to compromise targets. By definition, these exploits are available to attackers before they are patched (or possibly even known about) by vendors. Even when patches are released, they are of no use until they are not applied.
As reported by Websense, some 80 percent of enterprise Java requests are currently vulnerable to a Neutrino-launched attack.

Double-sided Defenses

Lowering these numbers, and thus improving enterprise security, is a double-sided coin for which both sides need improvement.
For IT organizations, it is easy to say "just install patches more quickly." But there are real-world challenges to consider. According to Alex Watson, director of security research at Websense, "Patch management can be a complicated and time-consuming process for organizations today. Many IT security teams lack the resources necessary to update application versions in real time."
Besides the sheer resource problem, said Watson, "new patches must be carefully tested for app compatibility." And, he added, "A single update and rush to patch could have a detrimental impact on business-critical applications."
In other words, patches can create unwanted side effects.
Watson suggests that one way for organizations to improve their ability to manage Java updates is to cull workstations that don’t strictly need Java, or a particular version of it. For example, if there are business critical applications that require the vulnerable Java 6 client, be sure that only those machines which need to run this application still possess Java 6. This at least reduces the potential attack surface area.
"Employees who do not require Java for their daily operations can either switch it off entirely or update to the most recent version," he said.
Better yet, Watson suggests organizations should pressure third-party vendors to maintain their applications to be compatible with the current state of Java. This would further reduce the need to run outdated versions of Java even on select machines.
On the vendor side of the coin, there is more Oracle can do to address the problem. First and foremost is to identify zero-day exploits more quickly and continue to reduce the vulnerable window before a patch becomes available.
Deploying the updates themselves is its own challenge. As described by Watson, "Java works across an astounding number of platforms. When Oracle rolls out an update, they are doing so across multiple operating system versions making the processes complex."
To that end, the new JDK 7u40 gives administrators control over which version of Java is used by which applications, which again helps reduce the aperture of exposure.

Set It and Don't Forget It

Java exploits are not going to disappear anytime soon. For the enterprise, the best defense comes down to reducing Java exposure and streamlining the update testing and deployment process.
Remember that by the time Oracle has developed a patch, the zero-day exploit has been in the wild for some time. Any additional time taken to deploy the patch across the enterprise is essentially a bonus for attackers.