Don't Be a Java Drive-by Victim

By: (CISSP, CISA)

Publication: The Nebraska Banker , May/June 2013

Many of us have seen this message: “3 Billion Devices Run Java: Computers, Printers, Routers, Cell Phones, Blackberry, Kindle, Parking Meters, Public Transportation Passes, ATMs, Credit Cards, Home Security Systems, Cable Boxes, TVs…”

Having trouble remembering where you’ve seen this message? Well, it’s flashed before you when you install the Java application. Here, Oracle is celebrating the broad use of their Java software. The danger in this statement is widespread distribution makes Java a lucrative target for cybercriminals. If you have doubts on this point, just ask Microsoft. Widely distributed software provides fertile grounds for cybercriminal exploitation.

Unfortunately, there are a number of security problems associated with Java. According to antivirus software manufacturer Kaspersky Lab, Java security holes were responsible for 50% of attacks in 2012, taking the 2011 vulnerability leaders crown previously held by Adobe Reader. Java vulnerabilities have gotten so serious that the Department of Homeland Security issued a Security Alert (TA13-010A) on February 6, 2013 advising users to disable usage of Java in their web browsers.

The prolific use of Java on both corporate and consumer systems regardless of operating system (Windows, OS X, Linux) makes most workstations and servers a potential target, providing an avenue to internal networks, straight through corporate firewalls. The attack scenario works like this: an unsuspecting user with a vulnerable version of Java visits a malicious website that is hosting a malicious Java applet, and voilà, you have a successful attack that just bypassed your firewall and installed malware on the user’s system. The cybercriminal now has a foothold on your network. This process is known as a drive-by download, because the user doesn’t need to do anything particularly wrong to invoke the compromise. There was no link to click, no pop up window, no video to play or any other required action by the user. The entire process happens without the user’s interaction and knowledge.

OK, enough about the problem, what can we do to combat Java weaknesses? Implementing one or more of the following recommendations will help keep your systems and sensitive data safe:

  • Uninstall Java completely if you don’t need it. Granted, many of us may not be able to take this advice because Java is highly integrated into many applications, both Internet-based and internal. But, for those of you who can, it’s the easiest and safest way to fix the problem.
  • Remove all versions of Java prior to version 7. Updating to version 7 will remove the latest version of Java 6; however, other versions of Java 6 will remain. This leaves old, vulnerable Java versions on your machines, which can be invoked by malicious websites, even though an updated version is available. Old versions need to be manually removed to preclude their use. Manually uninstalling old Java versions only has to be done once. Current versions of Java do stay installed after an upgrade.
  • For Java version 7 Update 10 and above, disable Java content in the browser. Oracle recently added the capability to disable Java content in the web browser to counter continuing discovery of vulnerabilities. Disabling Java in the browser will stop the Java plug-in from running in your browser and help defeat drive-by attacks. Disabling Java in the browser still allows it to be used with applications installed on the local workstation. Also, if you need to leave Java enabled in the browser, use the Java security level settings to control how the browser runs Java applications.
  • Don’t place full reliance upon the Java Auto Update feature (available only for 32-bit versions of Java) to keep Java updated throughout your network. While this feature is helpful, users are often confused about the legitimacy of this process. Some users will run the update and others will not. Users lacking local administrator rights will not be able to install the update anyway. In lieu of Java Auto Update, deploy a centralized patch management product capable of distributing Java updates. Or, at the very least, use a an automated software inventory application to periodically check the version of Java running on each system and then manually help the users that are not installing updates.
  • Utilize a web content filtering system capable of blocking known malicious websites. Some web content filtering systems maintain updated blacklists of known malicious websites. Users will not be able to reach the malicious websites, precluding a drive-by attack. This control is highly dependent upon the web content filtering vendor to update blacklists and also upon the company to implement the control evenly across the network.
  • Don’t allow Java to run applications where the publisher cannot be verified. Software from unknown publishers could be malware; therefore, it is a good idea to not allow Java to run unknown applications. This restriction can be configured in the Java console under the “Security” tab by selecting either the “Very High” or “High” settings.
  • Implement aggressive egress filtering on your firewall. Egress filtering limits network traffic that is leaving your internal network for the Internet. Even if malware gets installed on an internal machine, egress filtering may stop the malware from communicating with cybercriminals on the Internet. Only allow the outbound ports necessary to conduct business - all other ports should be blocked.