Developing a Java Management Strategy

I considered many ways to title this blog post: The Scourge That is Java; Die, Java, Die!; or, perhaps Java, it’s time we had a talk. As a security guy, Java has been my nemesis. It has been far more trouble than it’s worth. Multiple installed versions make management difficult, updating the enterprise never catches all of the PCs and irresponsible vendors may force us to stay on vulnerable versions in order to be supported. All the while, the Blackhole Exploit Kit gets updated within days of a new vulnerability and starts spraying out the infections.

One-hundred percent, yes, one-hundred percent of the malware infections I have been seeing in the last few months have begun from a malicious .jar file download. So I got to thinking, what do we really need Java for? Considering the demonstrated risks, do we need it at all?

Most people will say that you can never get rid of Java entirely. They may be right. There will always be that one business-critical application that requires it. They will also say that you simply cannot block Java from the Internet. This usually means they are mixing up Java with JavaScript.

Java applications are .jar or .class files which are downloaded to the local machine and executed locally. When sourced from the Internet, this means you are allowing arbitrary code to execute on your machine within software which has an ongoing track record of serious security vulnerabilities.  This just won’t do.

So I decided to look at the data. How many Java applications have people really been running, relative to the number of Internet domains they access? I used some queries similar to the following to search through months of logs:

grep ‘URL Accessed’ firewall.log | grep -E “\.jar$|\.class$”

After some further massaging, I had whittled the list down to ninety-six unique domains, many of which only had a single hit. There were less than twenty domains with more than five hits and of those, six had clear business usage. The question became clear: Why allow the entire Internet to potentially execute Java applications on all of these PCs when only a few legitimate sites needed to? The risks clearly outweighed the benefits.

So, how can you protect yourself against Java-based threats today? Consider these steps:

  1. Perform an assessment of internal business applications that may require Java. If there are none, consider uninstalling it entirely and only install it for those people that truly need it.
  2. Include language in your contracts with vendors that mandate they support the most recent versions of Java at all times.
  3. If you need it for some applications, but don’t need to use it through a browser, unplug it.
  4. If Java is needed internally, assess the need for Internet-based Java. Search your logs (you do have logs, don’t you?) for .jar and .class downloads. Normalize the results and try to understand what legitimate use your users have. Don’t be surprised if you find strangely-named downloads from TLDs like .in and .ru–be careful, these may be malicious.
  5. Finally, whatever is left, patch, patch, patch. Don’t wait for a monthly patch cycle. Patch within a week, at most. Antivirus will not save you here. Trust me. I have seen it time-and-time again.

These steps all really point to one thing: we have come to the point where Java cannot be trusted and instead of blocking known bad, a white list strategy is necessary. This can lead to reduced support costs and substantially reduced risk. Let the data do the talking, You might be surprised at what it has to say.

Posted in Risk Management, Secure Design, Systems Hardening, Vulnerabilities

Leave a Reply

Your email address will not be published. Required fields are marked *