Effective blocking of Java exploits in enterprise environments

Preface

"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.

The "typical useless" recommendations

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:

1. Update your Java.
2. 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.

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.

The solution

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.

Payload delivery

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.

Mobile devices

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.

Conclusion

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.

DNSSEC, from an end-user perspective, part 1

We all know since at least 1990 that the DNS protocol is insecure. Yet DNS is still the basis of almost all Internet communication. The biggest problem with DNS is that a malicious attacker can redirect victims, where victims try to connect to, e.g. safesite.com, but instead of this, they relate to the attacker's website. There are a lot of different ways to achieve this attack.

DNS cache poisoning the DNS server, "Da Old way."

The attacker forces the victim's DNS server to resolve a domain where the attacker is the authoritative name server, and the attacker sends additional information to the DNS server that he is also the authoritative name server for safesite.com. This information is cached and used later when the victim resolves safesite.com.

It is easy to protect against this attack, any decent DNS server should be able to protect against this attack by dropping this additional information from DNS responses.

DNS cache poisoning, "Da Kaminsky way"

An attacker can initiate queries to the victim's DNS server, and in the meantime, "flood" the DNS server with fake responses. The server will accept the fake response if the following conditions are right: 

• the DNS server receives the answers on the same IP as it expects (this is not an attack limitation), 
• the DNS server receives the answer to his question (again not a limitation, an attacker knows what he wants to attack),
• the random(?) port used to send the query matches the answer, 
• the random(?) 16-bit(!) unique transaction number in the answer matches with the query.

If the last two are not random, an attacker can easily poison the server in a matter of seconds. Or if your DNS server is behind NAT, the NAT can remove the randomness :-O

To protect yourself against this, you should randomize the source port and unique identifier better, and disable your DNS server as being an open recursive resolver.

Rogue DNS server via malware

This is pretty common in both banking trojans, adware, etc. The malware reconfigures the users configured DNS server to use a malicious one, either in the local OS settings or in the home router.

To protect against this: don't let malware in your environment ;)

ISP hijack, for advertisement or spying purposes

This is the worst of all. ISP's hijack non-existing domains, and display advertisements. And because they broke the RFC, it will break a lot of your applications. I bet ISPs still think about this as a good idea :(

Sometimes the ISP hijacks your connection because the government wants to spy on your communication or divert it. Use TOR wisely if you don't want to be a victim.

Captive portals

Sometimes captive portals use DNS hijacking to redirect the users to the default login page. Although it breaks things, it is still better than the ISP solution, because it is only a problem at the beginning of the connection, and not permanently.

Pentester hijacks DNS to test application via active man-in-the-middle

Although this is not malicious at all (developers might think otherwise), but a lot of application security tests (thick clients, mobile applications) can only be carried out via DNS spoofing. Application security testers can easily make this attack because they can place the host machine in a network segment where they can make an active man-in-the-middle attack and respond to DNS queries sooner as the official DNS server. Or simply set the DNS server to their own DNS server.

Malicious attacker hijacks DNS via active MITM

This is similar to the previous one, but the goal is different. Although an attacker with active man-in-the-middle position can attack the victim in 1000 different ways (like SMB relaying, capturing LM/NTLM network hashes, modifying clear-text traffics, etc...), DNS spoofing is one of them.

Having access to the DNS admin panel and rewriting the IP

I believe this is going to be a new trend. This attack is the most effective one, and the hardest to prevent. Usually, it is not the admin panel that is being hacked, instead an admin's password gets stolen, or the password reset is hacked.

You, as a client, can do three things to protect against this attack:

1. Choose a decent provider and prey :)
2. Put a registry lock on your DNS settings (serverDeleteProhibited, serverTransferProhibited, and serverUpdateProhibited). Although this additional layer is good enough today, I bet some motivated attackers will be able to successfully attack this. The attacker only has to:
   • know the phone number of the client, which will be called by the registrar
   • hijack the call (social engineering the phone company)
   • provide an individual security phrase (social engineering the client)
3. Or run your own DNS server (this is not a solution for everybody)

Conclusion 

Although almost all attacks can be mitigated one way or another, there was a desperate need to solve this DNS spoofing issue once and for all. And so it begins, DNSSEC has been developed.

In part 2, we are going to investigate DNSSEC, what you can expect from it, and what you can't.