Winter 2011: Password security standards and trendsWhile the Stuxnet worm, Zeus botnet and Operation Aurora have been
Requires Free Membership to View
grabbing the headlines over the last year, Brian Krebs of Krebs On Security
and Holly Stewart of Microsoft
have recently reported that the number of attacks against Java has been steadily increasing. As
Stewart writes, the increase in the number of attempted and successful attacks on Java has recently
surpassed even the number of attacks targeting PDFs and other attack vectors.
In this tip, we'll cover why Java has become such a tempting target for attackers, and how an enterprise can create a Java security framework to successfully ward off Java-based exploit attempts.
Current state of Java
The Java Runtime Environment, also known as JRE or simply Java, is installed on a large number of
diverse device types, including most PCs, Macs and Linux desktops, as well as smartphones and other
embedded devices. PDF readers and Flash players have a similar level of ubiquity when it comes to
types of devices, but Java is in a special class by itself because it was designed to be a
write-once-and-run-everywhere environment, including on embedded systems you might not expect.
While Java, which exists as both a programming language and as a piece of software that needs to be installed so Java programs can run, was developed to have additional protections that other programming languages didn't have -- like sandboxes and additional memory protections -- these have been bypassed by many recent exploits. Oracle Corp., which owns Java since acquiring Sun Microsystems Inc., issues frequent Java updates in attempt to address the vulnerabilities, and Java itself does include auto-update functionality, but this functionality isn't always reliable in ensuring the JRE is running the most recent version. To complicate things further, Apple Computer Inc. distributes its own version of Java that typically lags behind in the security-patching process.
As such, the Java JRE is an attractive target for criminals. Stewart reports that three Java vulnerabilities over the last year have accounted for over 3.5 million attacks on almost 2 million PCs, making Java one of the most attacked pieces of software.
Krebs reports that Java attacks have been included in exploit packs, allowing criminals to automate their attacks against the language. And enterprises using PCs aren't the only ones that should be worried: Some of the computers targeted by a recent Java exploit have been Macs. Mac security firm Intego Inc. recently reported that a malicious Java applet named Koobface has been infecting the Apple OS. Many of these infected computers have been exploited because of missing Java patches, and, as with recent Flash or PDF attacks, desktop antimalware defenses have been ineffective. However, Java attacks have been even more difficult for IPS/IDS vendors to detect on the network level because any potentially malicious Java applet would need to be executed in order to check for malicious code, requiring significant computing resources.
Enterprise defense strategy
Enterprises can mitigate Java-related risks by creating a Java
security framework. First, evaluate whether the enterprise needs Java installed on desktops or
servers, and, if it is not required, uninstall it or don't install it to begin with. Java should
only be installed if there is an application that requires it or if Java applets need to be
supported on desktops. This is basic advice, but if Java is not present, it cannot be
exploited.
Next, check to ensure that only current versions of Java are installed on client machines. These checks can be done with enterprise management software, scripting version checks or by manually visiting the Java download page, which will report the version of Java installed. In my experience, old versions are often left on systems to ensure backward compatibility, especially with home-grown applications. If Java is installed, it can be configured to automatically check for updates every day, but this would only be useful for home computers where users can update software for themselves. Enterprises should prioritize updating Java at the same level as applying Microsoft or Adobe patches. It may also be worthwhile to investigate some Java-specific security options -- available by using the Java control panel -- such as disabling users' ability to grant permissions to content from an untrusted authority, or enabling certificate checking to prevent potentially malicious applets from running. You may also want to enable logging to help detect whether and when malicious applets have been run. If your enterprise uses Firefox, the NoScript plug-in software could be used to whitelist approved Java applets to limit the risk of malicious Java applets.
Conclusions
The threats posed from out-of-date Java versions should not be underestimated, and Java patches
should be given the same priority as Microsoft or Adobe updates. Oracle is responsible for updates
to Java as Microsoft is responsible for its products, and Oracle should be held to the same
standards as Microsoft for updating its software, so, if at all possible, report any difficulties
caused by malware targeting Java to Oracle.
Enterprises should increase the prioritization of updating Java on their client systems to help prevent them from being exploited. They should also take this as a wake-up call to more carefully evaluate what software is installed on client computers and ensure updates are applied regularly to prevent system exploitation via the software they've decided they need. While this may still be a difficult battle to fight, it should also prompt enterprises to look beyond patching to more proactive controls like application whitelisting to prevent malicious software from running in the first place.
About the author:
Nick Lewis (CISSP, GCWN) is an information security analyst for a large Public Midwest
University responsible for the risk management program and also supports its technical PCI
compliance program. Nick received his Master of Science in Information Assurance from Norwich
University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining
his current organization in 2009, Nick worked at Children's Hospital Boston, the primary pediatric
teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State
University. He also answers your information
security threat questions.
This was first published in July 2011