Effective blocking of Java exploits in enterprise environments

"Java every day" was a joke about Java vulnerabilities, where almost every day, a new Java zero-day was seen. Recently, the "Java 0-day spotted in the wild" is no longer in the headlines every week (see http://java-0day.com), but Java exploits are still the most significant concern regarding exploit kits and drive-by-download malware. In a recent Kaspersky report, they found that about 90% of the exploit kits were trying to infect the victim machine via Java.

Okay, so we have a problem called Java in the browser, let's look for a solution!

The two most straightforward "solutions" of all are:

Both solutions are non-solutions for enterprises. Still, a hell a lot of in-house-built applications need old Java - e.g., 1.6.x, which is end-of-life since February 2013.

The next recommended "solution" is: "Create separate browsers for Internet and intranet usage. The intranet facing browser supports Java, the Internet-facing does not."

Although this sounds pretty effective, there are still a lot of problems with this approach. Now IT has to update two browsers instead of one. Users have to be trained, and in a web-security gateway (web proxy), one has to configure that this browser can go there, but the other can't, etc. And still, there might be Java applet based applications outside of the organization which has to be used by a bunch of people.

Next solution: "Use NoScript".

LOL. Teach NoScript to 50000 users, and see how they will learn the "Allow all this page" first, and "Allow scripts globally" the next time.

Next solution: "Click-to-play"

I think this is a good countermeasure, but from now on, the exploit maker either need an exploit to bypass the click-to-play, or to socially engineer the user to click, so this is not a bulletproof solution either.

Okay, so far, we have five totally useless recommendations. The next one seems pretty good at first sight: "White-list websites which need Java, and only allow Java to these sites."

Let's dig deeper. How can we "white-list" sites? This is not supported by Java out-of-the-box. In a decent web-security gateway, one can create white-lists, but we have to define a condition for Java traffic. A common misconception is to say: let's identify Java traffic for .class, .jar, and .jnlp file extensions, and only allow Java for white-listed websites. Although this will block some exploits, but not all.

Here is a screenshot from the trendy Neutrino exploit kit:

This is the .jar exploit. As you can see, there is no extension at all in the HTTP request (e.g., .jar). But what about the Mime-type in the response? It is video/QuickTime… But it is the jar exploit, with detection of 2/49 on Virustotal. And, yes, I'm aware of the fact that Virustotal statistics are useless, and AV has other possibilities in the exploit chain to block the malware being dropped. Or not :)

Two things can be flagged here as Java: the User-agent and the Mime-type in the request. I recommend checking for both. The User-agent can be reviewed via regular expressions, and if one matches, flag it as Java request.

Although not closely related to the exploit, but the malware payload delivery is exciting as well. After successful exploitation, the exploit payload downloads the malware from the same site. In a standard web-security gateway, executables can be flagged and blocked for average users. Now look at the Neutrino exploit kit:

No executable extension (e.g., .exe, .dll), the response Mime-type is faked to audio/MPEG, and even the malware is XOR encrypted with a 4 character key (I let the exercise to the reader to guess the XOR key). Also if the web-security gateway looks for file headers to identify executables, it won't find it. The malware is decrypted only on the victim, where the AV might or might not find it. Although the User-agent here is Java again, be aware of the fact that at this stage, the User-agent can be faked by the exploit.

Update 2013.01.02: I forgot to mention the case of SSL interception. Although in an enterprise environment, it is a good idea to intercept SSL traffic (except on finance, webmail, healthcare, etc. sites) to hunt for malware (and block Java), if you don't do this, it is not a problem. There is again a misconception that the User-agent of the client browser is not visible in an SSL connection on the proxy (web security gateway). Below is a screenshot to disprove this statement. In case of a transparent proxy, yes, there might be no user-agent.

If we white-list sites on the web-security gateway and block any other traffic when we see Java-based User-agent or content-type, we are right. Well, almost. As long as the client is in the enterprise… What you can do here is to enforce the mobile devices the use of VPN every time it is outside of the corporate network, and only connect it to the Internet through the corporate web-security gateway. I know this is still not a solution, but I can't think anything better at the moment. Leave a comment if you have a solution for this.

Now the only Java threat is that someone hacks one of the white-listed websites in a watering hole attack, and serves the java exploit from the same page. Not a likely attack, but possible for a real advanced threat.

If you are a CISO (or has the same position), you should proactively block Java exploits. White-listing websites which require Java is not impossible. Not a lot of sites use Java applets nowadays anyways. I would say average users see Java applets more in an exploit than in a legit site...

You can flag Java traffic via User-agent regular expression, or content-type (in the request), or both. Special care needs to be taken on mobile devices, which leave the enterprise on a regular basis. Of course, you will need other protections too, because this is not a 100% solution.

And if you are a plain home user, you can safely delete Java from your browser, or use a decent Internet Security Suite which can effectively block Java exploits.