Java in the cross-hairs of Enterprise Security

Enterprises seem to have a rather obvious love-hate relationship with our old pal Java.  It's a fat client we aren't thrilled with, but when it comes to cross-platform use there aren't really any other great alternatives right now.  In fact, if you look around you'll find that many of the security device management platforms are written in what? ...Java.

 

A few days ago a big bomb dropped as yet another Java 0-day was unleashed on the world, CVE-2012-4681.  It was reported in OSVDB [8/1/012], and immediately had coverage in Dave Kennedy's SET (social engineering toolkit) and MetaSploit.  This means that everyone now has access to exploitation of a critical flaw that exists virtually everywhere in the enterprise.

 

Queue the lamentation.

 

Perhaps one odd positive note for those, like me, who are still on Java6 and haven't updated to Java7, is that you're safe... so in an odd way not updating to the latest Java release actually saves your your skin from an issue that has no resolution right now.

 

 

Impact Assessment

 

Let's take a quick look at impact to your enterprise.

 

Java comes bundled with lots of software packages that require a heavy client.  Whether you're doing data-access, or something that required local filesystem access, or other 'heavy' client tasks... Java does show up all over the place.  The problem is that many of these software packages, whether they're a financial management package or managing a security device, require a specific version of Java which is often outdated.

 

Step 1 is to figure out what version of Java you're on.  I suggest this link on Oracle's site (since you know it's legit, mostly...): http://www.java.com/en/download/installed.jsp  Apparently my system is running the latest and greatest version, thanks to our enterprise security team, which makes this box vulnerable.

 

Vulnerable_Latest_Java.PNG

 

Luckily (this is sarcasm) Java can, and likely does, exist in multiple versions on any machine... which makes this even more fun.  Wait ... jre1.5.0_10 .... how did that get on there?!

 

Java_multiple_versions.PNG

 

Of course, you can't expect your end-users to maintain Java on their own enterprise-wide, so there are systems management tools that help you keep current (or at least updated) on Java in your enterprise.  The issue is of course what do you do when you have an enterprise application that relies on a version of Java that has issues?

 

Worse still, as I was looking for examples to share with you, one of my industry colleagues who always complains about Java compatibility issues with security tools shared with me a few nuggets of knowledge from his daily life.  For example, security tools like Rapid7's NeXpose, BlueCoat's SG proxies, and several McAfee products have awful, old Java management interfaces.  This doesn't bode well for security administrators who also browse the Internet.

 

You could, of course, turn Java off on your system, browser by browser...or you could uninstall it.  It appears that in Internet Explorer Java may be a little difficult to get rid of ... What's interesting is I wonder how many people have the "Insecure JRE versions" settings set (like below)... and why the current version of Java doesn't prompt you especially since there are known exploits out there for it?  Hello Oracle?

 

Insecure_JRE_Versions.PNG

 

So we're back to uninstalling Java to make your system safe for users who browse the Internet.  This is not a viable solution, especially if they have a requirement to use Java to access enterprise applications, partner/customer portals, or management tools.

 

The irony here is perhaps that security administrators are the high value targets here.  Odds are you're running Java to either run a security tool, or manage a console somewhere ... and you can't divorce yourself from the Internet.  Check to see if you're running OWASP Zap, Burp Proxy, or the widely-used free development IDE Eclipse!  Remember, just because you're not using Java in a browser (to manage a security tool) but rather in its own JVM, you can still be exploited because Java will install itself into your browsers as a plug-in by default!  Your only option is to use a multi-browser strategy (manage devices using Java in IE, while remembering never to use IE on the Internet...? )  This doesn't seem like a tenable or viable option for a long-term approach to security.  

 

 

So... I've gone and disabled Java on all my systems, and have told people I know that aren't technical to simply uninstall it if it's on their machines.  With Java being actively exploited, difficult to update, and HTML5 coming fast (no doubt with its own proven security issues) ... is the life-span for Java limited?

 

 

Additional Links:

Comments
h4zzmatt(anon) | ‎08-29-2012 11:04 AM

"still on Java6 and haven't updated to Java7, is that you're safe..."

 

You do know that java 6 is full of holes right? The fact you haven't upgraded does not mean you are safe. At all. if you do not know what you are talking about you should not say anything at all.

 

- H4zzmatt

secolive(anon) | ‎08-30-2012 09:40 AM

We can discuss whether Java is good or whether the world would be a better place without it, while being busy finding out how to mitigate the immediate risks, but I think we are missing some fundamental points here.


Vulnerability Management. What we have here is simply a vulnerability, without fix, and which can be exploited thanks to a plugin in the browser; that's for where the risk is significant. For other Java use cases (e.g. J2EE application servers, standalone Java desktop app), the issue is probably irrelevant in 98% of the cases. Very summarized, the real risk we are facing is that we have an unpatched, easy-to-exploit vulnerability in a browser plugin.

 

Now, for the easy questions: is it the first time we have a vulnerability in a browser or one of its plugins? Is it the last time? Won't there be any vulnerability anymore once you throw Java away? For the hard questions: what have you been doing to guard against such vulnerabilities? Have you tried using security plugins ala NoScript? Have you considered web proxies? Have you investigated virtualization techniques such as Bromium? If not, what are you waiting for?

 

I'll finish with a question for #infosec teams: how do you manage this Java 0-day right now? Were you able to significantly mitigate the risk? If not, well... don't you think you might be paving the road to your own irrelevance?

mhae(anon) | ‎09-18-2012 03:29 PM

I think that we need better tools to detect these types of issues in applications in general. Just look at the latest Internet Explorer 0-day issue (see http://news.cnet.com/8301-10805_3-57515097-75/microsoft-offers-advice-to-deal-with-ie-security-bug/). I don’t think HTML5 is the answer to security issues that manifest themselves in the browser.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
Community Announcements
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation