Java Web Vulnerability Mitigation on Windows

Introduction

The ubiquity of the Java browser plug-in has made it one of the largest attack surfaces on Windows clients for web-based attacks, particularly making it easy to perform undetectable drive-by download and "poisoning the well" attacks.  At any given moment, there is a pretty good chance that there is a Java 0-day in the wild.  Still, the promise of cross-platform "write once, run anywhere" code has led many companies to use the technology on their websites, leaving many organizations with no choice but to keep it around.  The purpose of this paper is to outline a set of mitigations that will allow an organization to use the Java plug-in for the sites that require it without exposing your fleet to attacks from websites that you do not have a business relationship with.

---

Java Version Control

Technical Challenges

Removing old versions of Java

Many versions of Java can exist simultaneously on the same system.  To ensure that the most up-to-date version is used, it is not enough to simply install it.  You must check for older versions present on the system and uninstall them.  Some examples of how to check for the existence of old version and remove them are in the example script below.

Installing Java

When installing/updating Java, it is important to consider the impact on the user.  The user should have a reasonable amount of time to save their work and close their browser before initiating the upgrade process so that productivity impact is kept to a minimum, so long as there is a maximum amount of time before automatically installing.

Operational Challenges

When a new version of Java is released, there is a pretty good chance that some users of Java-based applications will find that their new application no longer works with the updated version.  This is particularly likely when crossing major release versions (E.g. JRE 1.6-JRE1.7).

Exceptions

It is important to have an exception workflow prepared in advance because there is no way that the security, ops, and application support teams can know in advance what will break.  These exceptions should not be a black hole to throw your inconsistent configurations into indefinitely, however, but a way to keep up productivity while moving towards the goal of a more secure environment overall.

Exceptions should have the following qualities:

• Scoped to a particular timeline
• Accompanied by a plan on how to get the application up-to-date
• Tracked in a way where everyone is tracked in the same place, whether that's a tracking bug, support ticket, or spreadsheet

Application Support

To the extent possible, your operations/security teams should establish a rapport in advance with members of your largest users of Java applications so that they can coordinate compatibility testing with someone that is familiar with the software.  Security can consult and give recommendations on how to keep Java up to date, and your operations teams can make sure your platforms are running smoothly, but having trusted testers that know your applications can make a huge difference in terms of the amount of productivity affected by any changes to the JRE.

Vendor Management

It is normal to get pushback from users of Java application in the form of "I need an exception for [OLD VERSION].  The current version doesn't work with [APPLICATION]."  I have found that even if this is the initial response by the vendor, having people push back and get a timeline for when it will be supported has actually yielded positive results a large percentage of the time.

Isolation

Finally, if you have a business-critical application that absolutely cannot use a (more) secure version of the Java plug-in, then it may be worth assigning a specific machine or machines to be used for this purpose, isolating them as much as possible from your network with the least access possible to anything but the applications they need to use Java for.

Note:  if at all possible configure these machines so that you do not use any of your internal credentials.

---

Java Whitelisting in Internet Explorer

Internet Explorer Security Zones

When a web page is opened in Internet Explorer, it uses a series of signals to detect which security zone should apply.  In addition to IE's built-in logic, zones can be assigned by creating a manual list of domains and/or IP ranges.

Note: In IE 8 and higher, you can no longer easily see what zone you are in when looking at the browser.  You must hit the Alt key to see the menu bar, then select File → Properties.

Here are the default security zones that come installed with Internet Explorer.  Note that those numbers are the index that IE will use internally when referencing zones, rather than their names.

• 0 - My Computer
• Web pages launched from your hard drive.
• 1 - Local Intranet Zone
• Web pages hosted on your LAN/WAN.
• Note:  By default Internet Explorer will consider all sites that bypass the proxy in your proxy configuration script to be in this zone unless you manually configure membership.
• 2 - Trusted Sites Zone
• Be very careful with this zone.  Its permissions by default are very permissive, and can easily be used to bypass your security controls if a site in this zone is malicious or compromised.
• 3 - Internet Zone
• This is the general zone for most sites on the Internet.
• 4 - Restricted Sites Zone
• Put sites in this zone to enable the most restrictive settings by default.

Understanding the Internet Explorer Registry Settings

Whether you use the Internet Options GUI or set policies via GPO, you will be affecting the Registry settings that we will talk about below.  To see the official Microsoft documentation on advanced Registry settings for Internet Explorer, visit this site:  http://support.microsoft.com/kb/182569.  We will try to cover the most relevant sections, but won't cover every setting listed at that site.

Where settings are stored in the Registry

The Internet Explorer security settings are stored in four locations:

Preference Settings Locations

Machine

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

User

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings

Policy Settings Locations

Machine

HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings

User

HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings

Internet Explorer will look for policies in the following order:

1. Machine policy hive
2. User policy hive
3. User preference hive
4. Machine preference hive

Changing security settings through the Registry

Internet Explorer has a set of predefined security settings that can be set on a per-zone basis.  First you will need to figure out which location from above you want to use to configure IE.

Some important things to know before you start modifying these settings:

• Settings are created under one of the locations above + the Zone number
• For example: HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3
• The example above is where you would find security settings for the Internet Zone
• Machine settings override user settings if they conflict
• Unless specifically configured, IE will merge machine and user settings.
• Preference Settings locations are where changes are reflected when you make changes in the Internet Settings UI.
• If the Security_HKLM_only DWORD value is set to 1 under the Machine policy location below, only settings under HKLM will be applied.
• If Security_HKLM_only is not set, then Internet Explorer will combine the User and Machine settings, with the Machine settings overriding the user settings where there is a conflict.
• Most settings are DWORD values.  You can set them to 0, 1, or 3.  That is not a typo.  2 is not one of the settings, for some unfathomable reason.
• 0 - Setting is allowed
• 1 - Prompt the user
• 3 - Setting is prohibited
• Some settings are Enable/Disable only.
• 0 - Enable
• 3 - Disable
• A few settings, like 1C00 (Java Permissions, we'll come back to this) are special, and you will need to look them up.  We cover this specific setting below.

The official list of settings is at http://support.microsoft.com/kb/182569, but for convenience I've created a spreadsheet.

Creating a Custom Java Zone

Okay, we've hit all of the high points of how IE security settings are configured via the Registry, and now it's time to put it all together to create a custom Java zone for Internet Explorer.

Configuring security settings

Now that we know how to configure security settings in the Registry, the first big decision is, where do we want to add them?  If you recall we had four possible locations.  As a reminder, I'll put them below in the order they are processed by IE:

1. Machine policy hive
2. User policy hive
3. User preference hive
4. Machine preference hive

The choice is yours, but I recommend setting it in the Machine policy hive at HKLM\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\

This keeps non-administrators from being able to change the settings by default, and because it is applied at the machine level, it will apply to local users as well as domain users.  Note the small caveat that if you configure both a user and a machine policy, they will be combined, but the user will only see the user settings when looking in the Internet Settings GUI.

There are three separate settings that affect Java in IE

• 1402 - Scripting: Scripting of Java applets
• DWORD
• 0x00000000 - Allowed
• 0x00000001 - Prompt the user
• 0x00000002 - Disallowed
• 1605 - Run Java
• DWORD
• 0x00000000 - Allowed
• 0x00000001 - Prompt the user
• 0x00000002 - Disallowed
• Note:  This setting does not appear in the UI
• 1C00 - Java Permissions
• BINARY
• 00 00 00 00 - Disable Java
• 00 00 01 00 - High Safety
• 00 00 02 00 - Medium Safety
• 00 00 03 00 - Low Safety
• 00 08 00 00 - Custom
• Configuring "Custom" is out of the scope of this document

I recommend using the 1C00 setting to disable Java by adding it to Zones 0 through 4 (assuming this is your first custom zone, #5 will be your Java whitelist zone).

Adding domains to the whitelist

If you look under your Registry path under the ZoneMap key, you can pretty easily see how the domains are organized.  Each subdomain gets its own subkey of the parent domain for as many levels as is necessary.  Under each key there are one or more values that correspond to a protocol (or an asterisk for all protocols) that are a DWORD with the value of the Zone to assign it to (see picture below).

It's much easier, though, to edit it using the Group Policy Editor (gpedit.msc).  You'll find the setting under Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page.  The setting is called Site to Zone Assignment List.  It will pop up this dialog where you can type in the domains and add them to a zone number in a convenient grid UI:

Finish configuring the Java zone

So we've used 1C00 to block Java in zones 0 through 4, and whitelisted exactly which domains should be included in Zone 5.  Now it's time to add some finishing touches.  Are there any other settings that you want to change and have them be specific to this zone?  Look through the security settings again and see if there are any additional tweaks you want to make for this zone.

Don't trust, and verify

You probably did everything right, but as you are now well aware, it's easy to get confused in the web of Registry locations and settings.  Head over to the Java test page or another site with a known, non-malicious applet and make sure Java is being blocked where not whitelisted.

Disabling Java in Other Browsers

The NPAPI version of the Java plugin is used by Firefox, Chrome, Safari, Opera, and others, but not Internet Explorer.  If you want to make sure your users don't bypass your whitelisting by using an alternate browser, you can block the Java NPAPI Plug-in from running.  One option is to ban the file using a binary blacklisting solution like Bit9 Parity, Microsoft AppLocker, or one of the many other solutions.

You can find the file at the following path:

C:\Program Files (x86)\Java\jreX\bin\plugin2\npjp2.dll

Note: 64-bit versions of Java do not have '(x86)' in the path, and '\jreX\' means to replace the 'X' with the version number, for example '\jre7\'.

Future Alternate Mitigation Strategies

As it currently stands there is no known mechanism for whitelisting domains for the Java NPAPI plug-in on Windows, which is why we chose Internet Explorer.  There is a project upcoming that will change that, however.  It currently only supports Linux and OSX, but keep an eye on the project here:  https://code.google.com/p/nssecurity/.  Windows support is planned for later this year.

The NSSecurity wrapper will let you set up domain whitelisting for any NPAPI plug-in, not just the Java web plug-in, and has some neat features around managing plug-in versions.

Acknowledgments

This document is the end product of lots of hard work by many people in the Windows Infrastructure and Information Security groups, including but not limited to: Adam Mein, Larry Wu, Joaquim Metz, Cory Altheide, Will Beers, and many more.