Use Java Whitelisting To Further Secure Your Organization

If you were to ask any sysadmin what their biggest vulnerability is at the desktop level, they are most likely to say “Java.” In fact, Java has such a bad reputation for being exploited that it’s the butt of many IT jokes. Typically, if you mention Java to a sysadmin, you will very quickly hear a disappointed sigh in response.

Unfortunately, it’s almost impossible to get rid of across the organization because so many business processes rely on Java-based applications. Thankfully, starting in Java 7u40, Oracle has allowed sysadmins to control Java with a whitelist. The whitelist acts almost like a firewall in that the default rule is deny-all. You can whitelist Java applets based on domain or signing key.

This new capability allows sysadmins to secure their organization with a few .vbs scripts, some GPO, and a .jar file.

Software Prerequisites: Java JDK, Java JRE

Disable Java Cache

Throughout my testing, it has become apparent that disabling Java cache yields the best results. I would recommend doing this prior to starting the implementation of the Java whitelist. Below are User Login .vbs scripts that will disable Java Cache for XP and Windows 7. I am by no means a .vbs expert, so you may be able to tweak this into one script to handle both operating systems.

Link to XP

Link to 7

Generate a Code-Signing Certificate & Java Keystore

You will need to sign your white list .jar file in order for it to be processed by Java. I was able to generate a code-signing cert from our local CA in our Windows Domain. Getting that cert into a Java Keystore is a little tedious, but not difficult. Here’s what I did:

  1. Use Certificates MMC Snap-In to export certificate with private key (Example: C:\Users\username\cert-and-key.pfx)
  2. Open cmd.exe, navigate to the JDK bin directory (C:\Program Files\Java\jdk1.7.0_45\bin)
  3. Import .pfx to Java keystore with the following command
    1. Keytool -importkeystore -srckeystore C:\Users\username\cert-and-key.pfx -srcstoretype pkcs12 -destkeystore C:\Users\username\mykeystore.jks -deststoretype JKS
    2. Make note of the alias (something like le-codesigningcertificate-*) and copy it to a safe place.

Create the whitelist (DeploymentRuleSet.jar)

Now comes the fun part: creating the actual whitelist. The whitelist is basically a .xml file, packed into a .jar file (think tarball) and signed with your certificate. Oracle has a great example of said .xml file here: https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets

I’ve found it easiest to create the ruleset.xml file in the JDK bin directory as to avoid any issues with absolute paths in the following commands. Once you have your ruleset.xml created, it’s just a matter of creating the .jar file, signing it, and sticking it in the right place. The following commands assume you are in the JDK bin directory, and your ruleset.xml is also in that directory.

  1. Create the .jar file by issuing the following command:
    1. jar -cvf DeploymentRuleSet.jar ruleset.xml
  2. Sign the .jar file (you will need the alias from the previous section for this step):
    1. jarsigner -verbose -keystore C:\Users\username\mykeystore.jks -signedjar DeploymentRuleSet.jar DeploymentRuleSet.jar <paste alias from previous section here>
  3. Copy whitelist to correct location:
    1. Windows: copy DeploymentRuleSet.jar C:\Windows\Sun\Java\Deployment\
    2. Mac: cp DeploymentRuleSet.jar /etc/.java/deployment/

Confirm whitelist is being applied

The whitelist should get applied as soon as the .jar file is copied to the correct location. To test this, open the Java Control Panel and navigate to the Security Tab. You can then click on the “View the active Deployment Rule Set” link to see what whitelist is taking effect.

javasecuritytab

Further Notes

This took me a couple of tries to get right, so don’t get discouraged if you don’t get it right the first time. One very valuable piece of the Java whitelist is that it allows the sysadmin to specify which version of Java to run on each site. Therefore, if your organization has an application that is limited to a specific Java version, you can now lock down that version of Java to that specific application, while allowing all other applications to run the latest version of Java.