How are Java attacks getting through?
Posted by Charles Renert on 22 March 2013 09:37 PM
Were you aware that Java is increasingly being viewed as a security risk? Of course you were — recent high-profile attacks have firmly established the trend, so we're not going to do yet another roundup here.
Instead, let's drill in and try to understand the core problem. With so many vulnerabilities, it's hard to keep browsers up to date with the latest patched versions — especially because Java is updated independently from the browser. How hard is it? We decided to check.
We recently added Java version detection to our Advanced Classification Engine (ACE™) and pumped it into the Websense ThreatSeeker® Intelligence Cloud to get real-time telemetry about which versions of Java are actively being used across tens of millions of endpoints. Here's what we found (you may need to click on the graph to see all the detail):
Figure 1: Global distribution of Java Runtime Environment versions based on active browser usage
As you can see, Java versions are all over the map. At the time of this writing, the latest Java Runtime Environment is 1.7.17, but only about five percent of the overall mix are using it. Most versions are months and even years out of date. How does this translate into the attack space?
Exploit kits are a very common tool for distribution of many Java-based threats. From the billions of daily web requests being classified through our network, here is the breakdown of the active browser requests that are exploitable and which exploit kits have incorporated attacks for them.
Java Vulnerability Vulnerable Versions** Vulnerable Exploit Kits With Live Exploits
CVE-2013-1493 1.7.15, 1.6.41 93.77% Cool
CVE-2013-0431 1.7.11, 1.6.38 83.87% Cool
CVE-2012-5076 1.7.07, 1.6.35 74.06% Cool, Gong Da, MiniDuke
CVE-2012-4681 1.7.06, 1.6.34 71.54% Blackhole 2.0, RedKit, CritXPack, Gong Da
CVE-2012-1723 1.7.04, 1.6.32 67.72% Blackhole 2.0, RedKit, CritXPack, Gong Da
CVE-2012-0507 1.7.02, 1.6.30 59.51% Cool, Blackhole 2.0, RedKit, CritXPack, Gong Da
** All prior JRE versions below those listed are also vulnerable
It is probably no surprise that the largest single exploited vulnerability is the most recent one, with a vulnerable population of browsers at 93.77%. That's what the bad guys do — examine your security controls and find the easiest way to bypass them. Grabbing a copy of the latest version of Cool and using a pre-packaged exploit is a pretty low bar to go after such a large population of vulnerable browsers. Most browsers are vulnerable to a much broader array of well-known Java holes, with over 75% using versions that are at least six months old, nearly two-thirds being more than a year out of date, and more than 50% of browsers are greater than two years behind the times with respect to Java vulnerabilities. And don't forget that if you're not on version 7 (which is 78.86% of you), Oracle won't be sending you any more updates even if new vulnerabilities are uncovered.
How do you stop the onslaught if the patches aren't keeping up? Given the complexity and dynamism of exploit kits and their updates, exploit signatures do not suffice. Our protection model against new Java exploits is to use our analytics and real-time telemetry to proactively intercept new instances at every step of their attack strategy. Most prominently, ACE covers the exploit kit/exploit phase with a fine-grained knowledge of the expressible threats from all of the major kits, including not just the vulnerabilities, but also the obfuscation techniques, redirection techniques, and re-packaging of their dropper files. Here are just a few other ways we interrupt the malware kill chain to make it harder for the bad guys to drive right through this sizable hole in current IT infrastructure:
It's clearly not just the zero-day attacks that should be getting all of the attention.
Read more »