Endpoint
1/22/2013
03:11 AM
Connect Directly
RSS
E-Mail
50%
50%
Repost This

Tech Insight: 5 Approaches To Decaffeinating Java Exploits

Most enterprises might be stuck with Java, but there are ways reduce the effectiveness of recent and future zero-day exploits

The recent zero-day exploit for Java left enterprises scrambling to protect their networks from the active exploits out in the wild. The effectiveness of the exploit, its active use by exploit kits like Blackhole, and a window of time with no patch meant no one was safe -- at least not anyone who hadn't already taken steps to neuter Java by uninstalling or uncoupling it from their Web browsers.

Unfortunately, much misinformation has been published on what uses Java, which of those things are threatened by this exploit, and how to protect against the exploit. Before we focus on how to protect against the current (and future) Java exploits, let's quickly address the first two items.

First, Java is not JavaScript, but it does provide a cross-platform programming language that allows developers to write Java applets that run within a user's Web browser on different operating systems.

Second, it is this Java interface within Web browsers that exposes the vulnerable Java Runtime Environment (JRE) to malicious Java applets -- and not the server-side Java apps -- hat is vulnerable. If you want to know more about those two items, then take a look at Brian Krebs' piece, "What You Need to Know About the Java Exploit."

With those two items out of the way, let's dig into the top five ways to protect against the recent Java exploit, plus future Java zero-day exploits we'll likely see in the coming weeks and months.

1. Install Java 7 Update 11
Originally, this item was listed as "Do Nothing," but I didn't want to give the wrong impression. Installing the latest version prevents the recent zero-day exploit and requires users to explicitly acknowledge and allow unsigned Java applets to run each time. That's more that "doing nothing," though it does not do much in the way of mitigating future exploits. It's not like an attacker could ever steal a company's code-signing certificate that could be used to sign malicious Java applet.

2. Uninstall Java
This is highly effective ... for everyone except businesses that require Java for financial, reporting, and other types of business software built on Java. For example, does your company use any Oracle Forms Applications, firewall, and/or network management tools written in Java or some Cisco business products that leverage Java? If so, then this option isn't for you; you're stuck with Java indefinitely.

3. Allowing Java Only In Restricted Virtual Machines
Virtualization is one approach that can be used to provide a sandbox on the desktops of users that require Java for particular types of applications. Java could be completely uninstalled from users' workstations yet allowed to run inside of a virtual machine on those same workstations. Similar configurations have been used to isolate sensitive applications to be run from only virtual machines, so why not do the same for Java?

To tighten the security further, the Web browsers and network traffic from the virtual machine could be restricted to lists of predefined servers and Web applications, limiting the likelihood that casual browsing from the virtual machine could lead to compromise. And if Java were exploited through a Web browser in the virtual machine, the virtual machine could easily be reverted to a previous state or deleted and redeployed to its original state.

4. Decouple Java From The Web Browser
Removing Java from the Web browser is one of the more effective methods to keep Java on the desktop while mitigating the zero-day's method of attack. It is also likely to have the least impact on enterprise environments since the majority of enterprise Java applications are standalone applications. These applications run within the Java Runtime Environment and are not Java applets running within a Web browser.

With the release of Java 7 Update 10, Oracle has included the ability to easily decouple Java from the Web browser. Details on how to do this are located here: "Oracle: How do I disable Java in my Web browser?"

5. Use Separate Web Browsers -- And Only One with Java Enabled
This option is similar to No. 4 where Java is disabled within the Web browser. The difference is that this approach allows for more than one Web browser (i.e., Internet Explorer, Google Chrome, Firefox) to be installed on workstations, but only one has Java enabled in it. One browser can be used for daily Web browsing, another browser for more sensitive transactions, and maybe a third browser that has Java enabled and used only for websites that require Java.

The difficulty with this last approach is that it requires user training on which browser is appropriate for the task being performed. Technical controls can be put in place to prevent users from using a particular Web browser for the wrong task. The browsers could be configured to the security level that fits with their purpose. Proxy servers can define that limit with which sites the Web browsers can communicate.

Is this last approach practical? It depends on the organization, whether some of these controls are already in place, and if the number of Java applications being used is worth the time and effort required to implement the controls.

[The continued waves of Java zero-days have security experts recommending that enterprises re-evaluate how they use Java. See The Death Of Java In The Enterprise?]

Before deciding on one of the methods above, first take an inventory of which applications require Java, the users and/or groups that use those applications, and where Java is currently installed. Having that data in hand will help make choosing an option much easier.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
CHV4L
50%
50%
CHV4L,
User Rank: Apprentice
1/29/2013 | 6:51:30 PM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
so, ive blocked them and i feel better.

Am I correct in the fact that all java exploits will come via downlaoded jar or class files?
CHV4L
50%
50%
CHV4L,
User Rank: Apprentice
1/24/2013 | 10:03:39 PM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
ive been monitoring all the jar and class files flowing from the internet into our network. There are not many at all. Next week I will block all jar file and class files from the internet.
Andrew Binstock
50%
50%
Andrew Binstock,
User Rank: Apprentice
1/23/2013 | 3:51:19 AM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
For most organizations, #4 is the option that makes the most sense.
kjhiggins
50%
50%
kjhiggins,
User Rank: Strategist
1/23/2013 | 12:33:37 AM
re: Tech Insight: 5 Approaches To Decaffeinating Java Exploits
Wonder how many orgs are stuck with Java due to having apps that require it for financial,
reporting, and other biz solutions...

Kelly Jackson Higgins, Senior Editor
Dark Reading
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web