How are Java attacks getting through?

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:

 

  • Real-time intelligence to block lures, phishing, and other forms of social engineering coming across web, email, and mobile platforms
  • Real-time inbound intelligence to identify known or suspicious malware destinations and compromised sites 
  • Real-time outbound intelligence to identify command and control communication, bot networks, dynamic DNS requests, and fingerprinted data headed to the wrong people or places
  • Identifying malicious droppers both statically and behaviorally (via Websense ThreatScope™

 

 

It’s clearly not just the zero-day attacks that should be getting all of the attention.

20-20 Hindsight at the Big Top

RSA USA 2013 wrapped up last week and it had all the usual hallmarks of a modern security conference: storm troopers, casinos, free giveaways every few minutes, hawkers with headsets (much like the county fair), models in superhero costumes, attendees vying to collect the most free goodies, and of course the indispensable straight-jacketed unicycle-riding pitchmen.  The buzzwords this year included “Big Data”, “Mobile Security” and “Security Analytics”, not that there was any clear consensus about what those terms exactly meant or whether the solutions being peddled bore any resemblance to them.  For those with experience attending past conferences, it was just par for the course.

 

Outside of the circus tent, the high-profile hacks of major companies and web properties figured prominently in most presentations.  This wasn’t the usual FUD, either – even our conservative fellow researchers and technical presenters proclaimed that the bad guys had gained the upper hand, especially for the most sophisticated malware attacks from state-sponsored actors and financially-motivated cartels.  The technology put forth this year by the security industry in response was a little surprising, however.  Doubling down on the premise that “if the bad guys really want to get in, they will”, the emerging technology trend implied that it’s better to react quickly after you’re compromised rather than be under silent attack for months or even years like so many of the 2012-2013 examples have indicated.   There were over 11 different vendors that had created a behavioral sandbox (much like our ThreatScope) to examine the behavior of malware already in the environment.  There were at least 7 vendors that had created workflow tools to allow practitioners to record and investigate security events after the breach.  A few security vendors were touting their new-and-improved capabilities at repair and remediation.  One even declared that we now live in a “post-protection world.”  They all made for some fairly impressive demonstrations with all of those nifty post-breach attack details.

 

What was in short supply this year was an answer for why we were all there (in theory): “How do we stop the attacks?”  Where was the innovation around protection?   Protecting data from skilled attackers with newly crafted attacks designed to bypass existing security controls is indeed a hard enough task.  Now try adding in coverage for all the holes in emerging endpoints, mobility, and social web domains, and doing so inline, with low false positives and high performance.  Now try to figure out how to independently prove that all of this stuff works.  It’s a mammoth undertaking, and the unanimous consensus was that existing measures are not getting the job done.  Why not focus on THAT problem?

 

There were exceptions to this trend.  In addition to our own Chris Astacio’s standing-room-only talk on mass mobile attacks and Blackhole botnet dissection, Tomer Teller had some concrete insights into “Detecting the 1%” and Ed Skoutis presented CyberCity as a real-world model of how to pentest and ultimately protect infrastructure from physical attack.  There were other examples as well, but far too few.  

 

We’ve got to buck this trend and get back to basics – focus on stopping the attacks before they do harm or steal information.  True, we may never get it perfect, but we can certainly do a lot better.  It’s all well and good to put lots of 20-20 hindsight and forensics around an attack, but we would all prefer the deafening silence of a prevented attack over a decidedly louder postmortem of a successful data breach in all its glorious new detail.  

 

APT1: a prevention perspective

There’s been increased interest in targeted attacks and advanced persistent threats in the news lately, from the intrusions on large media outlets and hacks on social networking sites to a recent detailed report of the tactics behind the infiltration of a sophisticated attack family dubbed “APT1”.  Much of the controversy swirling around these reports stems from the attempt to identify the perpetrators behind the attacks — a decidedly difficult enterprise.  While the balance of evidence presented for APT1 does appear to point toward authorship in China (after exhaustive analysis), sophisticated attacks are faceless at the moment of attempted compromise.  

 

 

Here are a few data points we’ve already put together from our own analysis of the ThreatSeeker Network:

  • We have observed more than 2,000 unique cases of APT1 attacks since 2011 against all major industry segments.
  • China has a disproportionately large share of web-based attack traffic in the United States.  
    • For example, in February 0.49 percent of all web requests from US manufacturing companies land on servers in China.  11.21 percent of all malicious web requests from US manufacturing companies land on servers in China.  If you’re looking at traffic patterns, that’s more than a 20X traffic disparity toward malware.
    • US news & media companies are also disproportionately driven to malware located in China:   legitimate requests to China make up 7.47 percent of overall traffic, whereas China’s portion of all malicious traffic goes up to 21.21 percent.

  • As the APT1 report suggests, China currently has much less web-based attack traffic originating from the rest of the world at 0.76 percent.  That may change.

 

A more interesting question than authorship for us is: “How can you proactively stop targeted attacks like APT1?”  Signatures are obviously not the answer.  Here are some of the ways that we block APT1 along the kill chain without the need for signature updates:

 

  • Full content scanning within SSL, including preventing rogue certificates and criminal encryption (as we blogged about previously) 
  • File sandboxing (find two examples of APT1’s telltale behavior in ThreatScope reports here and here)
  • URL sandboxing in e-mails to prevent spear phishing
  • Data loss prevention technology to fingerprint and identify legitimate data as it exits
  • Dynamic DNS request interception
  • Web reputation /  destination awareness. Many domains, hosts, IP addresses, and even ASNs used by APT1 have been classified for years. Block known compromised hosts for the hops and the outbound C&C traffic.

 

 

One trend that you can confidently predict: the attackers will continue to adapt and get smarter, and the techniques to thwart them will need to do the same.

 

 

APT1: A Prevention Perspective

There’s been increased interest in targeted attacks and advanced persistent threats in the news lately, from the intrusions on large media outlets and hacks on social networking sites to a recent detailed report of the tactics behind the infiltration of a sophisticated attack family dubbed “APT1”.  Much of the controversy swirling around these reports stems from the attempt to identify the perpetrators behind the attacks — a decidedly difficult enterprise.  While the balance of evidence presented for APT1 does appear to point toward authorship in China (after exhaustive analysis), sophisticated attacks are faceless at the moment of attempted compromise.  

 

 

Here are a few data points we’ve already put together from our own analysis of the ThreatSeeker Network:

  • We have observed more than 2,000 unique cases of APT1 attacks since 2011 against all major industry segments.
  • China has a disproportionately large share of web-based attack traffic in the United States.  
    • For example, in February 0.49 percent of all web requests from US manufacturing companies land on servers in China.  11.21 percent of all malicious web requests from US manufacturing companies land on servers in China.  If you’re looking at traffic patterns, that’s more than a 20X traffic disparity toward malware.
    • US news & media companies are also disproportionately driven to malware located in China:   legitimate requests to China make up 7.47 percent of overall traffic, whereas China’s portion of all malicious traffic goes up to 21.21 percent.

  • As the APT1 report suggests, China currently has much less web-based attack traffic originating from the rest of the world at 0.76 percent.  That may change.

 

A more interesting question than authorship for us is: “How can you proactively stop targeted attacks like APT1?”  Signatures are obviously not the answer.  Here are some of the ways that we block APT1 along the kill chain without the need for signature updates:

 

  • Full content scanning within SSL, including preventing rogue certificates and criminal encryption (as we blogged about previously) 
  • File sandboxing (find two examples of APT1’s telltale behavior in ThreatScope reports here and here)
  • URL sandboxing in e-mails to prevent spear phishing
  • Data loss prevention technology to fingerprint and identify legitimate data as it exits
  • Dynamic DNS request interception
  • Web reputation /  destination awareness. Many domains, hosts, IP addresses, and even ASNs used by APT1 have been classified for years. Block known compromised hosts for the hops and the outbound C&C traffic.

 

 

One trend that you can confidently predict: the attackers will continue to adapt and get smarter, and the techniques to thwart them will need to do the same.