Earlier this week, Microsoft released a couple of patches that addressed vulnerabilities in our good friend Group Policy. First, I will say that it’s relatively rare to see such vulnerabilities directly effect Group Policy function, like this one does. That’s a good thing. That said, this one, while not trivial to exploit, is relatively serious and should be addressed. I’ve spent a lot of this week talking to IT Pros about what this is and how it should be implemented and I thought I’d share some of those thoughts here.

Background

First, some background. Why is this called “JASBug”? Well, have a look at this page to understand the origin of the name, and the folks that first reported it to Microsoft. For more Microsoft specific details on it, have a look at this TechNet posting, which describes the two hotfixes–MS15-011 & MS15-014 related to this.

So, what is the JASBUG? Put simply, it’s exploiting the following scenario. Let’s say you walk into a coffee shop, library, airport with your corporate laptop. Keep in mind, that as the JASBUG FAQ points out above, this is not strictly limited to public places–anywhere where someone could tap into your network, could create the conditions for this vulnerability, including your own corporate network. In fact, I think it’s fair to say that the real risk of this vulnerability is not in public spaces that you infrequently visit, but, your own corporate network that you spend most days on. In any case, let’s say that you connect to the public wireless and log in with your domain cached credentials. As a normal course of log in (or in the background every 90 minutes or so) your domain-joined machine fires up the Group Policy engine and reaches out to find out what policies should be applied to the user and computer. To do this, it of course queries for a domain controller in it’s domain, and then asks for the list of GPOs that apply to it. This communication happens over LDAP and SMB, by and large–the former talking to AD and the latter talking to SYSVOL to get Group Policy settings. An intrepid bad guy, sitting on the wireless network and sniffing all it’s traffic, could create a system that responds to your domain’s requests for GP (yes, they could install a <mycompany.com> DC, esp. if you frequent that coffee shop a lot!) and redirect your traffic (if they owned the Wireless Access Point) to their fake DC (keeping in mind that creating a fake DC is not a trivial thing. Again, this is where the risk is more likely on your own corporate network). Once there, they could deliver instructions to the GP engine, that, for example, removed all security settings that were previously delivered to your workstation. Or, deliver a corrupt security settings file. In that latter case, a bug in GP processing caused Windows to punt on security settings and revert to essentially a vanilla configuration (That particular bug is what MS15-014 fixes). Once your system’s security position has been compromised, all bets are off as to what the attacker can do to/with your machine. Note that this issue is not just limited to security settings. Pretty much anything that executes automatically, such as logon scripts, could be hijacked and owned by this attack. And pretty much anything Group Policy can do–from copying files to running scheduled tasks, could be introduced to your machine using this hijack approach. Not good.

The Fix

I’ve already mentioned that MS15-014 fixes the behavior of the Security Client Side Extension (CSE) when it receives a corrupt security configuration file from SYSVOL. Essentially what it does is revert the system to the last known good security configuration that was delivered. So instead of “punting” and returning to a vanilla configuration, it assumes what you had before is just fine. Great! But how do we prevent someone from hijacking my GP processing cycle in the first place? That’s where MS15-011 comes into play. This particular fix adds “hardening” to specific UNC Paths. What is hardening? It optionally provides three things. First, it provides integrity on the connection to the shares you designate. This essentially means a tamperproof SMB connection between client and server, where SMB packets are signed and it’s very difficult for someone to hijack that communication. The second protection is to enforce mutual authentication. This means that not only does the server authenticate itself to the client as the right server to talk to, but the client also authenticates itself to the server as the right client. The third protection is privacy, which forces the communication between client and server to be encrypted.

NOTE ON PRIVACY OPTION: From the Microsoft KB article:

SMB Encryption is supported by the SMB client only on Windows 8, Windows Server 2012, and later versions, and then only when communicating with SMB Encryption-capable servers (such as Windows 8, Windows Server 2012 and later versions). If you configure RequirePrivacy=1 on clients that do not support SMB Encryption or for UNC paths hosted by servers that do not support SMB Encryption, you will have a configuration in which the SMB client will be unable to access the specified path.

So, be careful turning on the RequirePrivacy option!

Implementation

These three new hardening options are configured on a per-share (or per server) basis. Microsoft recommends that the first two shares you harden are SYSVOL and NetLogon, which run on each of your domain controllers by default. SYSVOL is where Group Policy gets most of the settings information contained in GPOs and Netlogon is the default share for logon scripts that are defined on AD user objects. So how do you implement this hardening? When you install MS15-011, it will install a new ADMX template file in c:\windows\policydefinitions, called NetworkProvider.ADMX (and it’s corresponding ADML file in the language specific sub-folder (e.g. en-us for US English)).

NOTE: If you have a Central Store where you store your ADMX files for your domain, then you will need to copy networkprovider.admx from your local machine up to \\<domain>\sysvol\<domain>\Policies\PolicyDefinitions, and the corresponding networkprovider.adml to the language-specific folder under that location.

When you open GP editor on a machine where this patch is installed, you will now have a new option under Computer  Configuration\Policies\Administrative Templates\Network\Network Provider. Under there, you will see one setting–Hardened UNC Paths, as shown here:

Hardened UNC Paths Policy for JASBUG

Once you enable this policy above, click the Show button to bring up the list box element, where you can enter the UNC paths you wish to harden, and the options of Integrity, Privacy and Mutual Authentication you want to enable. For this bug, Microsoft is recommending the minimum hardening be of the SYSVOL and Netlogon shares on all of your domain controllers, and using the Mutual Authentication and Integrity flags. This would look like the following within the policy above:

Netlogon and SYSVOL hardening for JASBUG

Note that I specified the Netlogon and SYSVOL shares using a wildcard where the server name would go (e.g. \\*\SYSVOL). This reads as, “all servers that have a share called SYSVOL. If you plan to harden other shares location, you can also use wildcards to say, “all shares on a given server”, using this notation: \\ServerName

What To Harden?

Beyond SYSVOL and Netlogon, I’ve had a fair number of folks ask if they should harden all shares within their environment? The answer to this will depend upon the environment and it’s own risk assessment. Remember that part of the reason Microsoft is recommending that Netlogon and SYSVOL be hardened is that these are two paths that a client system will communicate with in an automated fashion (e.g. through GP Processing) and download and execute files without user intervention. So, the hijacking of these automatic execution operations takes on some urgency. That said, you have to ask yourself, for your shares, what is the risk if a given share is hijacked and the user is fed a different file? Certainly if you have other file shares that contain files that are used for automated (non user-driven) operations, those should likely be hardened, especially if those operations are privileged. Beyond that, hardening those departmental public drives that contain Word docs may or may not be important to you. There is overhead in enabling these protections on all shares, as the additional signing, mutual authentication and encryption processing, will take more cycles on client and server. But again, it’s a risk assessment that you must perform based on your own environment.

UPDATE

Just an update to let folks know that Microsoft posted an FAQ on these hotfixes here: http://blogs.technet.com/b/askpfeplat/archive/2015/02/23/guidance-on-deployment-of-ms15-011-and-ms15-014.aspx

Hope this helps!

Darren