Archive

Posts Tagged ‘Java’

Blocking Vulnerable Java Requests at the Network Layer

August 30th, 2012 No comments

Another week, another Java exploit. Java as a server platform and as a desktop/mobile still has a role to play in modern computing, but the same really can’t be said for the browser side of the technology. As seen in both the general populace and in monitoring metrics from my own networks, Java is one of (if not the) top targets for drive-by exploits. In my work environment, where the cause of a desktop compromise is known, Java is responsible for over 90% of the initial compromise vectors.

So let’s talk defense here for a bit. Security and administrative teams have several options (as well as challenges) in dealing with the risk associated with Java in their environment:

  1. Remove it. Depending on the shop, this may or may not be an option. Like any other software platform, if it isn’t needed the safest course is to remove the package entirely. This is not always an option though as there are still a number of business related applications that require Java as a desktop or browser platform.
  2. Disable the browser plugin only. This is the functionality that is exploited in drive-by or targeted link attacks, so if is not needed (but a desktop Java environment is) disabling the browser object cuts way down on the attack surface. Not all shops have this ability, however, especially for non-IE browsers. Asking the users to do it themselves without the ability to monitor compliance is not really an effective option here.
  3. Patch it. In regular circumstances, this is a great idea. Java is notorious for being hard to patch in stand-alone mode (who hasn’t seen the ‘Click here to update Java’ followed by the ‘A new update is ready to install’ pop-ups. Just install it, I already clicked you once!). Many smaller shops (and some big ones too) lack the tools to effectively manage and patch 3rd-party software. And in this specific case there isn’t even a patch for the issue, so additional controls are needed to provide a sufficient level of protection.
  4. Push the control onto the network. This can be deployed as a stand-alone measure or in conjunction with other controls listed here (my preferred option). Network controls such as forward proxies or IPS devices that can filter on the layer 7 payload can be used to help prevent a system that has missed the previous sets of controls from being exposed to the final exploit payload. In fact, the rest of this article will be about utilizing a Bluecoat web proxy to prevent the Java plugin from reaching the internet in general.

Configuring Bluecoat to deny access to the Java User Agent

While these intructions are for the Bluecoat series of web proxies, the same methodology should be portable to whatever proxy you have in place. If the proxy cannot do deep inspection on SSL wrapped connections, you may lose some level of control though I don’t believe that I’ve seen a site that specifically served general target malware over SSL in my day-to-day monitoring.

First, we’ll create a new policy line and set the action to ‘Deny’ (the default typically). Move the policy into place in your policy chain so that it will be most effective (I’ve place mine in the first couple of slots, though your set-up may vary).

Depending on other controls or requirements, you can set the ‘Service’ to only look at defined HTTP/HTTPS traffic or the catch-all ‘Any’ service.

Building the Rule Objects

Let’s start by setting the source object. Right click on the Source field that probably reads as ‘Any’ and select ‘Set’. In the ‘Set Source Object’ window that comes up, click ‘New’ and select ‘Combined Source Object’. Give the object a name, something like ‘Unpatched Java’.

Now to create the specific objects that will detect the use of the Java plugin. Luckily, when Java creates an HTTP socket connection, it set’s it User-Agent request header to the full version of the JRE in use. This is specifically the case here when the browser plugin requests a JAR or class file from an HTTP server. It is this request that we specifically want to block. To start, let’s create a new ‘Request Header’ object by clicking New->Request Header.

Name this new object something like ‘AllJavaUserAgents’. Set the ‘Header Name’ to ‘User-Agent’. Set the ‘Header Regex’ to:

.*Java/1.[4-7].0_[0-9]+.*

AllJavaUserAgents

This will now match on any Java 4 through Java 7 User-Agent string (if you still have Java versions earlier than 4 in your environment, you probably don’t have a Bluecoat proxy or a security program in general). Example matches would include:

User-Agent: Java/1.6.0_33  
User-Agent: Mozilla/4.0 (Windows 7 6.1) Java/1.7.0_05

Save this new object and create a second Request Header object. This one will be for fully patched (securely patched, not just latest version patched). Set the name to something like ‘FullyPatchedJava1_6’ and the ‘Header Regex’ to:

.*Java/1.6.0_3[3-4].*

FullyPatchedJava

Once Java 7 is patched, we can create a third object that encompasses the patched version string as well so that this rule can be used to protect against threats to machines that have not been patched to the latest versions, but for now only the 6 branch is secure (in a relative sense).

Back in the Combined Object Editor window, select the ‘AllJavaUserAgents’ object and add it to the first/top rule block. Select the ‘FullyPatchedJava1_6’ object and add it to the second/bottom rule block. Click the ‘Negate’ check box for the second/bottom rule block. This sets up a match condition for any Java User-Agent string except Java/1.6.0_33 or Java/1.6.0_34 (v. 34 is a bug fix release, and not a security release but can still be found out there).

Final Unpatched Java CSO

From here, depending on your security requirements, you can either add this object directly to the ‘Source’ field of your policy rule or add it to another combined source object as needed. We had specific subnets that we were applying this rule to, so I created a second combined object rule that matched on both the subnets in question and the ‘Unpatched Java’ object.

Likewise, if there are specific known-good destinations that you need the Java plugin to run on, these can be added as a Negate rule to the ‘Destination’ object. This is where additional controls at the network layer come in handy over just disabling the plugin altogether.

Once complete, save and install the new policy. It is probably a good idea to set up a trace or log event on the policy line itself to allow for monitoring of blocks, both from an incident response and tuning perspective.