greptrick.com

As with most sizable organizations it is near impossible to uninstall or completely disable Java which sent us on a hunt for a feasible way to contain Java based attacks. What we came up with was restricting it to run only in trusted zones. This worked for APPLET tags when encountered in IE. 

What this does is block any applet from running if it is not part of a trusted internet zone. First thing is to identify all the internal trusted zones and add them. Next allow the user to trust their own zones. Most of the time it seemed they knew when there was an applet they wanted to run. To enable this there is a simple registry change value 1C00 in 

 HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 to a value of 0
*Note: (original 10000). 

This will prohibit Java from running in the “Internet Zone.” Now for internal sites you can just whitelist them as a “Trusted Zone” for java to run properly. Of course this can be done via GPO for all internal sites and if there are some identified external sites that java is required. 

For some fun stats, an enterprise of 15,000 endpoints went from ~1.5 take aways per day down to about 1-2 per month due to Java a java drive by style attacks.

For most organizations updating java is a Herculean effort. So the whitelisting method from within Windows can be a viable alternative that can be quite effective. In recent months Oracle has released Java 1.7U40 which includes whitelisting. This is nice because it will work for browsers other than IE but odds are if you can get to 7U40 you have a good handle on patching anyway so this is less of an issue (except for 0-day). Java calls their implementation “Deployment Rule Sets” (DRS). 

A DRS is just a XML configuration file listing the location or hash of a jar and the action to take. You can bypass some of the pop-ups (some pop-ups can’t be disabled such as JAR unsigned), you can flat out block the jar or run the default actions as you would if DRS wasn’t defined. The XML file is parse sequentially so place your allowed jars at the top of the file and place a catch all block rule at the bottom. 

Deployment of the rule set is as simple as packing in a signed (from a trusted 3rd party) jar file named DeploymentRuleSet.jar and deploying to the endpoints to be controlled. 

Java based whitelisting is a very powerful feature but it is limited. With MSFT based whitelisting users can individually whitelist java for their own uses, but it is limited only to IE. Java based on the other hand does stop end users from whitelisting however it is a larger effort to whitelist and you either have to manage many lists for individual or groups of users or you have to whitelist sites for everyone, package and re-push.

Also, deploy EMET

Sources:

Oracle docs on the setup.

http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/deployment_rules.html
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets

Push TrustedSites via GPO

http://www.makeuseof.com/tag/configure-trusted-sites-internet-explorer-group-policy/

Java Whitelisting from MSDN

http://blogs.msdn.com/b/ieinternals/archive/2011/05/15/controlling-java-in-internet-explorer.aspx