Effective blocking of Java exploits in enterprise environments

Nytro · January 1, 2014

[h=3]Effective blocking of Java exploits in enterprise environments[/h]

[h=2]Preface[/h] "Java everyday" 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 biggest 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.

[h=2]The "typical useless" recommendations[/h] Okay, so we have a problem called Java in the browser, let's look for a solution!

The two simplest "solutions" of all are:

Update your Java.
Remove Java from your browser.

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.

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 has 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 needs an exploit to bypass the click-t-play, or to socially engineer the user to click so this is not a bulletproof solution either.

[h=2]The solution[/h] Okay, so far we have five totally useless recommendations. The next one seems pretty good at the 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 from 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 screenshots from the very popular 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 a 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 checked via regular expressions, and if one matches, flag it as Java request.

[h=2]Payload delivery[/h] Although not closely related to the exploit, but the malware payload delivery is interesting as well. After successful exploitation, the exploit payload downloads the malware from the the same site. In a normal 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). Even 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.

[h=2]Mobile devices[/h] 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 good. 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.

[h=2]Conclusion[/h] 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.

Posted by Z at 1:30:00 PM

Sursa: Jump ESP, jump!: Effective blocking of Java exploits in enterprise environments