Java vulnerabilities are increasingly exploited by attackers to infect computers, and the problem could become worse if Oracle doesn't do more to secure the product and keep its installation base up to date, according to security researchers who will talk about Java-based attacks at the Black Hat USA 2012 security conference.
A large number of computers get infected today through drive-by-download attacks performed with the help of Web exploit toolkits -- malicious Web applications designed to exploit vulnerabilities in widespread browser plug-ins like Flash Player, Adobe Reader or Java.
Java was acquired by Oracle as part of its 2010 acquisition of Sun Microsystems.
A couple of years ago the most targeted browser plug-ins were Flash Player and Adobe Reader, but many of today's Web exploit toolkits rely heavily on Java exploits, said Jason Jones, a security researcher with HP DVLabs, Hewlett-Packard's vulnerability research division.
Jones has monitored the development of some of the most commonly used Web exploit toolkits, like Blackhole or Phoenix, and will present his findings at Black Hat on Thursday.
One clear trend is that Web exploit toolkit developers are increasingly focusing on Java exploits, Jones said. They are also integrating exploits for new Java vulnerabilities at a much faster pace than before.
In some cases attackers reuse exploit code that gets published online by security researchers after Oracle patches the vulnerabilities. However, they modify it and apply different obfuscation techniques to it in order to evade detection by security products.
"Overall we have seen the amount of Java malware increasing over time, based on our telemetry," Jeong Wook Oh, a researcher with Microsoft Malware Protection Center, said via email. Oh is scheduled to talk about recent Java exploitation trends and malware at Black Hat on Thursday.
Cybercriminals are attracted to Java exploits because they can have very high success rates. For example, one particular exploit integrated into Blackhole in 2011 had an over 80 percent success rate, Jones said.
This is because users are not deploying the available security updates in a timely fashion, which is going to be an even greater problem now that attackers are targeting new Java vulnerabilities faster.
Adobe dealt with similarly low patch adoption rates for Flash Player and Adobe Reader by improving the update mechanisms for those products and even implementing automatic updates for Flash Player.
Those changes had a direct impact on the overall frequency of attacks targeting the two products and so did other in-depth security measures taken by the company, like the introduction of a security development cycle (SDL) -- a series of code security reviews and development practices that aim to reduce the number of vulnerabilities -- or the implementation of sandboxing technologies, said Carsten Eiram, the chief security specialist at vulnerability management firm Secunia.
Java already has a sandbox that should theoretically keep third-party code contained. However, a single vulnerability can break this security model and allow attackers to execute malicious code directly on the system, Oh said.
Java has some pretty big security problems at the code level, Eiram said. Many of the vulnerabilities found in Java are basic ones that could be prevented by a good SDL program, he said.
Eiram researched the effects that Microsoft's SDL program had on Microsoft Office over the years and found that it has led to a significant decline in the number of traditional buffer overflow vulnerabilities found in the product to the extent that they are almost non-existent in Office 2010.
The researchers agree that Oracle needs to take actions that would make Java a less attractive target for attackers.
"Automatic background update will provide a lot of benefit if it is implemented by Oracle," Oh said. "The attackers are abusing the time gap between patch release and user updates."
The majority of Java exploits used by attacker right now target vulnerabilities that have already been patched by Oracle. However, Eiram believes that this will change and attackers will soon start targeting unpatched (zero-day) Java vulnerabilities instead of Flash ones, which are currently a favorite target for zero-day attacks.
Oracle could have a hard time dealing with such attacks, because they're not one of the most responsive vendors at the moment, Eiram said. They avoid communicating openly about security issues or confirming their existence, even to security researchers who report vulnerabilities to them, he said.
Software vendors that develop widely deployed browser plug-ins like Java, Flash or Adobe Reader, have a responsibility to make them as secure as possible and respond to security incidents as fast as possible, Eiram said. Adobe made a lot of improvements regarding this in the last few years, but Oracle remains too slow and unresponsive he said.
"Any 3rd party software with a large user base can be a possible target in the future," Oh said. "But as long as you don't put any efforts to make your software more secure and your software has a large user base, there is no reason for the bad guys to stop abusing the vulnerabilities found in your software. It is especially true when the bad guys can have high success rate with those vulnerabilities."
In the absence of better action from plug-in developers, some browser vendors have built defenses at the browser-level in order to protect their users.
Google Chrome automatically disables outdated plug-ins that are known to be vulnerable. Mozilla has a plug-in blacklist for Firefox and actually used it to block vulnerable Java plug-ins in April in response to widespread attacks targeting a vulnerability in older versions.
Click-to-play is another browser feature that can prevent plug-in attacks because it prevents the automatic playback of plug-in-based content. The feature is already present in Chrome and is currently being built into Firefox.
Jones recommended that users enable click-to-play when available in their browser. Another defensive approach is to delete the Java plug-in completely if not needed, he said.
Unfortunately, not everyone can do this, especially in a business environment, where Java is needed for many internal applications. For example, some banks still have their e-banking systems built around Java, Eiram said.