Today we are releasing MS15-011 & MS15-014 which harden group policy and address network access vulnerabilities that can be used to achieve remote code execution (RCE) in domain networks. The MS15-014 update addresses an issue in Group Policy update which can be used to disable client-side global SMB Signing requirements, bypassing an existing security feature built into the product.MS15-011 adds new functionality, hardening network file access to block access to untrusted, attacker controlled shares when Group Policy refreshes on client machines. These two updates are important improvements that will help safeguard your domain network.
What’s the risk, i.e., what’s the attack scenario?
Let’s looks at one of the typical attack scenarios as outlined in the below diagram.
This is an example of a ‘coffee shop’ attack scenario, where an attacker would attempt to make changes to a shared network switch in a public place and can direct the client traffic an attacker-controlled system.
In this scenario, the attacker has observed traffic across the switch and found that a specific machine is attempting to download a file located at the UNC path: \\10.0.0.100\Share\Login.bat .
On the attacker machine, a share is set up that exactly matches the UNC path of the file requested by the victim: \\*\Share\Login.bat.
The attacker will have crafted the contents of Login.bat to execute arbitrary, malicious code on the target system. Depending on the service requesting Login.bat, this could be executed as the local user or as the SYSTEM account on the victim’s machine.
The attacker then modifies the ARP table in the local switch to ensure that traffic intended for the target server 10.0.0.100 is now routed through to the attacker’s machine.
When the victim’s machine next requests the file, the attacker’s machine will return the malicious version of Login.bat.
This scenario also illustrates that this attack cannot be used broadly across the internet – an attacker need to target a specific system or group of systems that request files with this unique UNC.
What were the Group Policy vulnerabilities?
An RCE vulnerability existed in how Group Policy received and applied policy data when connecting to a domain. Concurrently, a vulnerability existed whereby Group Policy could fail to retrieve valid security policy and instead apply a default, potentially less secure, group policy. This could, in turn, be used to disable the domain enforced SMB Signing policy.
What did we fix under MS15-014?
The risk of circumventing SMB Signing was fixed by correcting how Group Policy would behave when it fails to retrieve a current, valid security policy. After applying the fix, Group Policy will no longer fall back to defaults and will instead the last known good policy if a security policy retrieval fails.
What did we harden under MS15-011?
While SMB Signing safeguards against Man-In-The-Middle attacks, with the vulnerabilities like the above in Group Policy it is possible to disable it. But more importantly, SMB Client doesn’t require SMB Signing by default so it is possible to direct the domain related traffic, especially the unencrypted traffic, to attacker controlled machines and serve malicious content to the victims in response. To block this kind of attacks we added the ability to harden the UNC path access within domain network.
Universal Naming Convention (UNC) is a standardized notation that Windows uses to access file resources; in most cases these resource are located on a remote server. UNC allows the system to access files using the standard path format: \\<hostname>\<sharename>\<objectname>, for example, \\contoso.com\fileshare\passwords.txt, without requiring the application or user to understand the underlying transport technology used to provide access to the file. In this way, the UNC client in Windows abstract network file technologies, such as SMB and WebDAV, behind a familiar file path syntax. UNC paths are used in Windows in everything from printers to file shares, providing an attacker a broad surface to explore and attack. To properly address this weakness in UNC, we had to improve UNC to allow a server to authenticate itself to a client, thereby allowing the client machine to trust the content coming from the target system and be protected from malicious file shares.
How did we harden it?
When an application or service attempts to access a file on a UNC path, the Multiple UNC Provider (MUP) is responsible for enumerating all installed UNC Providers and selecting one of them to satisfy all I/O requests for specified the UNC path. On a typical Windows client installation, MUP would try the Server Message Block (SMB) protocol first, but if the SMB UNC Provider is unable to establish an SMB connection to the server, then MUP would try the next UNC Provider and so on until one of them is able to establish a connection (or there are no remaining UNC providers, in which case the request would fail).
In most scenarios, the security of the server is paramount: the server stores sensitive data, so file transfer protocols are designed in such a way that the server validates the client’s identity and performs appropriate access checks before allowing the client to read from or write to files. The trust boundary when Group Policy applies computer and/or user policies is completely reversed: the sensitive data is the client’s configuration and the remote server has the capability of changing the client’s configuration via transmission of policy files and/or scripts. When Group Policy is retrieving data from the policy server, it important that the client performs security checks to validate the server’s identity and prevent data tampering between the client and the server (in addition to the normal security checks performed by the server to validate the client’s credentials). It is also important that MUP only send requests for Group Policy files to UNC Providers that support these client-side checks, so as to prevent the checks from being bypassed when the SMB UNC provider is unable to establish a connection to the server.
Group Policy isn’t necessarily the only service for which these extra client-side security checks are important. Any application or service that retrieves configuration data from a UNC path, and/or automatically runs programs or scripts located on UNC paths could benefit from these additional security checks. As such, we’ve added new feature, UNC Hardened Access, along with a corresponding Group Policy setting in which MUP can be configured to require additional security properties when accessing configured UNC paths.
When UNC Hardened Access is configured, MUP starts handling UNC path requests in a slightly different manner:
Each time MUP receives a request to create or open a file on a UNC path, it evaluates the current UNC Hardened Access Group Policy settings to determine which security properties are required for the requested UNC path. The result of this evaluation is utilized for two purposes:
MUP only considers UNC Providers that have indicated support for all of the required security properties. Any UNC Providers that do not support all of the security properties required via the UNC Hardened Access configuration for the requested UNC path will simply be skipped.
Once a UNC Provider is selected by MUP, the required security properties are passed to that UNC Provider via an Extra Create Parameter (ECP). UNC Providers that opt-in to UNC Hardened Access must respect the required security properties indicated in the ECP; if the selected UNC Provider is unable to establish a connection to the server in a manner that satisfies these requirements (e.g. due to lack of server support), then the selected UNC Provider must fail the request.
Even 3rd party applications and services can take advantage of this new feature without additional code changes; simply add the necessary configuration details in Group Policy. If a UNC Provider is able to establish a connection to the specified server that meets the required security properties, then the application/service will be able to open handles as normal; if not, opening handles would fail, thus preventing insecure access to the remote server.
Consider the following scenario:
Contoso maintains an Active Directory domain named corp.contoso.com with two Domain Controllers (DCs) named dc1.corp.contoso.com and dc2.corp.contoso.com.
A laptop is joined to the aforementioned domain.
Group Policy is configured to apply a Group Policy Object (GPO) to the laptop that configures UNC Hardened Access for the paths \\*\NETLOGON and \\*\SYSVOL such that all access to these paths require both Mutual Authentication and Integrity.
Group Policy is configured to apply a GPO to the laptop that runs the script located at \\corp.contoso.com\NETLOGON\logon.cmd each time a user logs on to the machine.
With the above configuration, when a user successfully logs onto the laptop and the laptop has any network access, Group Policy will attempt to run the script located at \\corp.contoso.com\NETLOGON\logon.cmd, but behind the scenes, MUP would only allow the script to be run if the file could be opened and transmitted securely:
MUP receives a request to open the file at \\corp.contoso.com\NETLOGON\logon.cmd.
MUP notices that the requested path matches \\*\NETLOGON and paths that match \\*\NETLOGON are configured to require both Mutual Authentication and Integrity. UNC Providers that do not support UNC Hardened Access or indicate that they do not support both Mutual Authentication and Integrity are skipped.
The Distributed File Server Namespace (DFS-N) client detects that the requested UNC path is a domain DFS-N namespace and begins its process of rewriting the UNC path (all DFS-N requests will be subject to the same security property requirements identified by MUP in step 2):
The DFS-N client uses the DC Locator service and/or DFS-N DC Referral requests (depending on the OS version) to identify the name of a DC on the domain (e.g. dc1.corp.contoso.com).
DFS rewrites the path using the selected DC (e.g. \\corp.contoso.com\NETLOGON\logon.cmd becomes \\dc1.corp.contoso.com\NETLOGON\logon.cmd). Since Mutual Authentication is required and the target is expected to be a DC, DFS utilizes a special Kerberos Service Principal Name (SPN) to verify that the name retrieved in the previous step is indeed the name of a DC (if the name is not a DC, Kerberos authentication would fail due to an unknown SPN)
If there are additional DFS-N links in the specified UNC path, the DFS-N client continues iterating and replacing paths to DFS-N links with paths to available targets until it has a UNC path that does not have any remaining DFS-N links.
The final UNC path is passed back to MUP to select a UNC Provider to handle the request. MUP selects the SMB UNC provider since DCs utilize SMB to share the NETLOGON and SYSVOL shares.
The SMB UNC Provider establishes an authenticated session with the selected SMB Server (if an authenticated session is not already present). If the authenticated session is not mutually authenticated (e.g. authentication was performed utilizing the NTLM protocol), then SMB UNC Provider would fail the request to open logon.cmd since mutual authentication requirement identified in step 2 could not be met.
The SMB UNC Provider enables SMB Signing on all requests related to logon.cmd since MUP informed SMB that integrity is required for this request. Any attempts to tamper with the SMB requests or responses would invalidate the signatures on the requests/responses, thus allowing the receiving end to detect the unauthorized modifications and fail the SMB requests.
In this scenario, the client-side requirement of end-to-end mutual authentication and integrity protects the laptop from running a logon script located on a malicious server via the following security checks:
The requirement for Mutual Authentication ensures that the connection is not redirected to an unexpected (and potentially malicious) SMB Server when SMB Client attempts to establish a connection to the requested UNC path.
The requirement for Integrity enables SMB Signing, even if the SMB Client does not require SMB Signing for all paths by default. This protects the system against on-the-wire tampering that can be used to change the contents of the logon.cmd script as it is transmitted between the selected DC and the laptop.
The combined requirements for both Mutual Authentication and Integrity ensures that the final rewritten path selected by DFS-N Client matches a path allowed by the DFS-N namespace configuration and that spoofing and/or tampering attacks cannot cause DFS-N client to rewrite the requested UNC path to a UNC path hosted by an unexpected (and potentially malicious) server.
Without these client-side protections, ARP, DNS, DFS-N, or SMB requests sent via Group Policy over untrusted networks could potentially cause the Group Policy service to run a the logon.cmd script from the wrong SMB Server.
How do I configure to protect myself/my users?
A word on CVD and fixing difficult problems
In many regards, this security ‘fix’ is more accurately described as completely new functionality in Windows. Adding something of this scale posed a unique challenge to security response. Software vulnerabilities are typically more narrowly constrained in both investigation and remediation – and most response is structured to address that scope. Among the benefits of Coordinated Vulnerability Disclosure (CVD) is it provides for greater flexibility and deeper collaboration with researchers to take the necessary time and perspective to deliver the most complete security solutions to customers. In this case we tackled a vulnerability that required a much greater scope in engineering to deliver a solution.
Most vulnerabilities reported to the MSRC are bugs in a single component, which are investigated, understood, and fixed within industry accepted response times. Creating the new functionality of UNC Hardening, however, required an entirely new architecture which increased development time and necessitated extensive testing. Thanks to CVD, and the close collaboration with the passionate security researchers who reported the vulnerability, Microsoft had sufficient time to build the right fix for a complicated issue. If the security researchers were not willing to refrain from disclosure until our fix was ready, customers would have been put at risk.
Microsoft offers its appreciation to the CVD community and a special thanks to the reporters of the issue which has resulted in UNC Hardening: Jeff Schmidt of JAS Global Advisors, Dr. Arnoldo Muller-Molina of simMachines, The Internet Corporation for Assigned Names and Numbers (ICANN) and Luke Jennings from MWR Labs.
The letter S appears nowhere in the word "dollar", yet an S with a line through it ($) is unmistakably the dollar sign. But why an S? Why isn't the dollar sign something like a ฤ (like the former South Vietnamese 
