Archive for the ‘Policy Enforcement’ Category

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:



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:



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.

Rogue Machine Discovery Using DHCP Hostname Analysis

October 23rd, 2009 No comments

An important aspect of defending one’s network is controlling what devices actually get on said network. In fact, several of the big name IT regulatory schemes – SoX specifically, though probably some of the others as well – have specific requirements to control access to network assets. Depending on the nature of a business, the financial resources available, and the prevailing culture of the workplace this can either be a relatively simple task or something approaching the Sisyphean level. There are also two levels of people we are trying to keep off: end-users who are either ignorant or dismissive of established policy concerning network access and the “determined individual”, be them malicious or just not wanting to follow the rules.

This process was developed at ThatPlaceIWorkâ„¢ as a stop-gap measure to help determine machines that were attached to the internal network but which were not maintained or managed by us. It is definitely aimed at the first group mentioned above – it is somewhat trivial to overcome by a knowledgeable person, but that is not the goal of the exercise. Our business, by the nature of our industry, is very free-flowing and the culture does not adapt well to overt controls – any controls that are leveraged have to walk a fine line between effectiveness and intrusiveness. The vast majority of machines that are being placed on the network that should not be there are either personal machines of employees or those of guests being brought into the agency. Some of these machines come in infected with malware, as determined by our IPS systems. They have no business being on the internal network and there is written policy against such a practice. Weak consequences of policy infringement keep these policies from being effective on their own. Therefore we developed this process to help control the use of undesired machines until such time as a better process could be put in place. Again, this is not a NAC solution, it is merely a way to quickly narrow down a list of machines that may be on the network in defiance of policy. If you really want to keep machines properly segmented, either implement something like wired 802.1X (which we are moving to) or full-body cavity searches at the door.

Read more…