Feb 11

MS15-011 & MS15-014: Microsoft Active Directory Group Policy (GPO) Vulnerabilities Patched

On February’s Patch Tuesday (2/11/2015), Microsoft released two patches that fix issues with the way Group Policy is processed by the client. Interestingly enough, one of these vulnerabilities (MS15-014) makes the other one (MS15-011) not only feasible, but quite capable.

The Attack Scenario:

  • An attacker leverages the vulnerability described in MS15-014 to prevent/stop Group Policy settings from being applied, including SMB Signing which enables the client to verify a valid DC is providing the Group Policy data.
  • The attacker successfully prevents legitimate Group Policy settings from being applied, so they revert to default which disables SMB Signing.
  • This enables the attacker to move onto phase 2: trick the target computer to connect to an attacker machine instead of a Domain Controller. This can be performed through several methods, though ARP cache poisoning is the one Microsoft specifically calls out (in a coffee shop scenario).
  • The target computer reaches out to the Domain Controller when a user logs on to run the logon script: \\domain.com\NETLOGON\logon.bat
  • The target computer connects to the attacker’s hosted share instead of the Domain Controller and runs the file provided by the attacker’s system. Either the attacker configures the same shares and files on the attacker system or use a custom SMB server that responds to any request with files of the attacker’s choice.
  • The target computer runs the attacker’s file which executes code as the local user (logon script) or as System (Group Policy). The attacker has now executed code on the target system without any obvious event which would trigger an alert (other than perhaps an IDS triggering on ARP cache poisoning).

The Microsoft Security Research & Defense article, “MS15-011 & MS15-014: Hardening Group Policy“, calls out the “coffee shop” attack scenario where the user’s domain-joined computer attempts to connect to a Domain Controller to execute a file. Since the attacker can re-route communication to a system of their choosing, the target computer can be exploited leveraging both vulnerabilities.

NOTE:
While the coffee shop scenario described by Microsoft is the most likely – i.e. a roaming user on a laptop connected to an untrusted network (WiFi), it is possible for this to work on a corporate LAN/WAN.
In order to perform this attack, the attacker must be able to control a computer on the same network as the target computer and be able to redirect the target’s traffic to the attacker controlled system (instead of the valid Domain Controller).

Additionally, even if the patch has been applied, if SMB signing is not enabled, an enterprise may still be vulnerable.

MWRInfoSecurity has a write-up on exploiting this vulnerability on a corporate LAN.

Attack Mitigation:

  • Ensure roaming users (laptops) have VPN software installed and required for connections outside of the corporate network. This provides some protection, but an attacker controlled DNS may still be able to force traffic destined for a corporate DC to go outside of the VPN tunnel.
  • Apply the patches to all domain-joined computers (sorry Windows 2003, no soup for you!) [Windows 2003 is End-of-Life, support-wise in July 2015, right?]
  • Configure Group Policy to apply to all domain-joined computers with the following minimum Hardened UNC Paths (see below for step-by-step configuration):
    • \\*\NETLOGON    RequireMutualAuthentication=1, RequireIntegrity=1
    • \\*\SYSVOL    RequireMutualAuthentication=1, RequireIntegrity=1

NOTE:
It may be possible to configure IPSec Policies (Kerberos) on Windows 2003 for standard Windows communication ports to ensure that this communication only occurs with other domain-joined computers. This is a type of mitigation, not prevention, though additional security could be applied for more complete mitigation (and assumes that an attacker hasn’t compromised a domain-joined system).

Vulnerability and Patch Detail:

MS15-014: Microsoft KB3031432 – Vulnerability in Microsoft Windows Could Allow Elevation of Privilege

MS15-014 fixes an issue with Group Policy that could revert GPO configured settings back to default when current policy cannot be retrieved. After applying the patch, the Group Policy client will apply the last known good policy. One of the key issues is that by preventing a Group Policy from retrieving the current, valid Group Policy to apply security settings, SMB Signing is disabled (default setting) which normally protects against Man-In-The-Middle attacks by validating the server’s identity.

MS15-011: Microsoft KB3000483 – Vulnerability in Group Policy Could Allow Remote Code Execution

MS15-011 improves the way Windows handles UNC paths greatly improving security. What’s interesting about the “patch” is that it is more than a security patch; it completely changes the Multiple UNC Provider (MUP) behavior to only allow connections to sources that support required security levels:

  • Mutual Authentication: server/client identity verification
  • Integrity: ensure data is not modified in transit
  • Privacy: ensure data is encrypted

Standard UNC shares used during user logon:

  • Group Policy configuration files and scripts (startup, shutdown, etc) are stored and shared out on Domain Controllers’ SYSVOL share (\\DOMAIN\SYSVOL\DOMAIN\Policies).
  • Logon scripts are stored and shared out on Domain Controllers’ NETLOGON share (\\DOMAIN\NETLOGON).

Prior to this patch & GPO configuration, it was possible to redirect a client to connect and run code on a UNC path that is not a valid server.

NOTE:
The patch needs to be installed and the UNC paths that should be protected require configuration in Group Policy (Hardened UNC Paths) to protect against spoofing.

 

The UNC Hardened Access feature enables specific servers or shares to be “tagged” with additional information to inform MUP and UNC providers of security requirements beyond the UNC provider’s defaults. In particular, the following three security properties are supported:

  • RequireMutualAuthentication=<0|1> – When this property is set to 1, the selected UNC provider requires that the UNC provider can authenticate the identity of the remote server (in addition to the server’s verification of the client’s identity) in order to block spoofing attacks.
  • RequireIntegrity=<0|1> – When this property is set to 1, MUP and the selected UNC provider must use integrity checks in order detect when third parties manipulate requests or responses while in transit between the client and server in order to block tampering attacks.
  • RequirePrivacy=<0|1> – When this property is set to 1, MUP and the selected UNC provider must use a form of encryption in such a way that when third parties see communication between the client and the server, they cannot see any sensitive information that is contained within the communication.
The Group Policy UNC Hardening configuration is not cumulative. This means if the Microsoft recommended minimums are configured at the domain-level and an OU admin sets a GPO configuring UNC Hardening for all of the resources in that OU (specific shares on specific servers), the domain UNC Hardening settings are dropped.

SMB v1: SMB Signing optional
SMB v2: SMB Signing required

SMB v3: SMB Encryption available.

The default Domain Controllers Group Policy sets SMB Signing to Always.

Microsoft’s Ask Platform PFE blog has additional information on this issue:

What about a Windows client that has the settings enabled, but the UNC shares are located on a network device that is not Windows based?

For Windows clients communicating with 3rd party SMB Servers, compatibility depends on the policy settings configured by the system administrator and the protocol version and/or optional protocol features supported by the 3rd party SMB Server:

· If the administrator has configured a path to require Integrity, but the 3rd party SMB server is an SMB1 server that does not support SMB Signing, Windows will disallow the connection (SMB Signing is an optional protocol feature in v1, but is required in v2+)

· If the administrator has configured a path to require Privacy, but the 3rd party SMB server does not support SMB Encryption, Windows will disallow the connection (SMB Encryption is only supported in SMB v3+)

· If the administrator has configured a path to require Mutual Authentication, but the 3rd party SMB Server does not support Kerberos (or the client is unable to find appropriate Kerberos credentials), Windows will disallow the connection.

 

There is NO Windows 2003 MS15-011 patch.

Windows Server 2003 is listed as an affected product; why is Microsoft not issuing an update for it?
Although Windows Server 2003 is an affected product, Microsoft is not issuing an update for it because the comprehensive architectural changes required would jeopardize system stability and cause application compatibility problems
. Microsoft recommends that security-conscious customers upgrade to a later operating system in order to keep pace with the changing security threat landscape and benefit from the more robust protections that later operating systems provide.

Patch Group Policy Configuration

The patch needs to be applied AND a Group Policy configuration is required to fully protect against this vulnerability.
If you are having trouble finding the UNC Hardening Group Policy settings, apply the patch and reboot. If you have the Group Policy Central Store enabled, you will need to copy the NetworkProvider.admx and NetworkProvider.adml files from your patched server to the Central Store (\\DOMAIN\SYSVOL\DOMAIN\Policies\PolicyDefinitions) before the Group Policy editing tool (GPMC, etc) will see the settings.

Windows 2003 Server SMB Client vs. SMB Server Behavior

There seems to be confusion about Microsoft’s statement that Windows 2003 Server will not be patched for MS15-011.

NOTE: The Domain Functional Level (DFL) doesn’t matter as long as the Domain Controllers are running Windows Server 2008 or newer. If you are running Windows 2003 Server, it’s time to upgrade to a newer OS since 2003 is End of Life (EOL) July 14th, 2015.

There are two different parts to this story:

  1. Windows Server 2003 SMB Client Behavior: No Change
    There is a member server called ADSAPP01 in Active Directory running Windows 2003 Server SP2
    There is no patch for this server since it is running Win2k3. This means that any UNC Hardening that is attempted to be applied to it (via GPO or local registry setting) for whenADSAPP01 connects to shares on the network will not be effective. When ADSAPP01 does reach out to another computer to access file share data, it won’t include any UNC Hardening qualifications in the request (since Win2k3 doesn’t support UNC Hardening) and the file share access will occur as it always has.
  2. Windows Server 2003 SMB Server Activity:
    There is a member server called ADSFP01 in Active Directory running Windows 2003 Server SP2
    There is no patch for this server since it is running Win2k3, though the MS15-011 patch and associated UNC Hardening GPO has been deployed for every computer running a supported OS in the AD domain.

There are three options with UNC Hardening: RequireMutualAuthentication (0/1), RequireIntegrity (0/1), and RequirePrivacy (0/1).

When a fully-patched Windows 7 client (ADSWK7) that has UNC Hardening enabled for servers & shares on the network connects to ADSFP01 to access data on a hosted share, there are several different results based on how UNC Hardening options are configured.

  • Mutual Authentication
    If the fully-patched Windows 7 client, ADSWK7, requests file share access to Windows Sever 2003 server “ADSFP01” and that request includes “RequireMutualAuthentication=1”, this request must use Kerberos authentication since NTLM is not supported for mutual authentication by default (Windows Server 2008 R2 supports additional Security Support Providers, SSPs, that could provide mutual authentication for other auth types). Assuming the SMB connect request communication includes Kerberos auth for the user, the connection to the file share should be successful.
    This setting seems to result in the same behavior whether the destination server SMB share is patched or not or is Windows Server 2003 or a newer OS version.
  • Integrity
    If the fully-patched Windows 7 client, ADSWK7, requests file share access to Windows Sever 2003 server “ADSFP01” and that request includes “RequireIntegrity =1”, this request requires SMB signing for the SMB communication for this session. However, SMB v1 doesn’t support per session SMB signing, SMB v2 does. Windows 2003 R2 and earlier only support SMB v1. This means that if there is an existing SMB (v1) connection to a share on the server that doesn’t require integrity, this secondary request to another file share will fail and the client will not be able to connect to the new file share.
    This setting may cause issues when clients connect to a SMB share with RequireIntegrity=1. The workaround is to set Windows Server 2003 servers to always require security signatures which enforces SMB signing for all SMB connections.
  • Privacy: SMB encryption is ONLY supported in Windows 8/Windows Server 2012 and newer
    If the SMB request includes “RequirePrivacy=1”, this request requires SMB encryption for the SMB communication for this session. The only operating systems that support SMB encryption is Windows 8/Windows Server 2012 and newer.
    This means that only a computer running Windows 8/Windows Server 2012 (or newer) can connect to a file share when the SMB request includes “RequirePrivacy=1” and only when connecting to a computer running Windows 8/Windows Server 2012 (or newer).
    This setting may cause issues when clients connect to a SMB share with RequireIntegrity=1.
    Any GPO configuration that configures shares on a Windows Server 2012 (or newer) server to “RequirePrivacy=1” will only allow computers running Windows 8/Windows Server 2012 (or newer) to successfully connect.

To summarize, if your Active Directory environment doesn’t have all computers running Windows 8/Windows Server 2012 (or newer), you probably don’t want to configure RequirePrivacy=1 for any servers/shares. Although, configuring this setting for Windows Server 2012 (and newer) servers creates file shares that can only be accessed from clients running Windows 8/Windows Server 2012 (or newer) which may be a desirable configuration depending on your security posture.
SMB Signing Reference: http://support.microsoft.com/kb/887429

NOTE:
If you have Windows Server 2003 servers hosting file shares in your environment, it is advisable to get them moved over to Windows 2008 R2 (or newer) soon. Leveraging domain DFS namespaces can help this switchover since there is a common namespace for all shares.

Windows UNC And MS15-011 UNC Hardening

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.

MS15-011 Hardening:

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).

 

MUP UNC Hardened Access Behavior

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:

  1. 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.
  2. 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.

 

 Configuring UNC Hardened Access through Group Policy

The UNC Hardened Access feature enables specific servers or shares to be “tagged” with additional information to inform MUP and UNC providers of security requirements beyond the UNC provider’s defaults. In particular, the following three security properties are supported:

  • RequireMutualAuthentication=<0|1> – When this property is set to 1, the selected UNC provider requires that the UNC provider can authenticate the identity of the remote server (in addition to the server’s verification of the client’s identity) in order to block spoofing attacks.
  • RequireIntegrity=<0|1> – When this property is set to 1, MUP and the selected UNC provider must use integrity checks in order detect when third parties manipulate requests or responses while in transit between the client and server in order to block tampering attacks.
  • RequirePrivacy=<0|1> – When this property is set to 1, MUP and the selected UNC provider must use a form of encryption in such a way that when third parties see communication between the client and the server, they cannot see any sensitive information that is contained within the communication.

To enable UNC Hardened Access through Group Policy, follow these steps:

  1. Open Group Policy Management Console.
  2. In the console tree, in the forest and domain that contain the Group Policy object (GPO) that you want to create or edit, double-click Group Policy Objects.Forest name/Domains/<Domain name>
  3. (Optional) Right-click Group Policy Objects, and then click New.
  4. Type the desired name for the new GPO.
  5. Right-click the desired GPO, and then click Edit.
  6. In the Group Policy Object Editor console, browse to the following policy path:
    Computer Configuration/Administrative Templates/Network/Network Provider
  7. Right-click the Hardened UNC Paths setting, and then click Edit.
  8. Select the Enabled option button.
  9. In the Options pane, scroll down, and then click Show.
  10. Add one or more configuration entries. to do this, follow these steps:
    1. In the Value Name column, type the UNC path that you want to configure. The UNC path may be specified in one of the following forms:
      • \\<Server>\<Share> – The configuration entry applies to the share that has the specified name on the specified server.
      • \\*\<Share> – The configuration entry applies to the share that has the specified name on any server.
      • \\<Server>\* – The configuration entry applies to any share on the specified server.
      • \\<Server> – The same as \\<Server>\*

      Note A specific server or share name must be specified. All-wildcard paths such as \\* and \\*\* are not supported.

    2. In the Value column, type the name of the security property to configure (for example, type RequireMutualAuthentication, RequireIntegrity, or RequirePrivacy) followed by an equal sign (=) and the number 0 or 1.Note Multiple properties may be assigned for a single UNC path by separating each “<Property> = <Value>” pair by using a comma (,).
  11. Click OK two times, and then close the GPO editor.
  12. If you created a new GPO earlier, link the GPO to one or more domains. To do this, right-click the desired domain, click Link an Existing GPO, select the newly added GPO, and then click OK.
  13. To test the new or updated GPO, log on to a computer to which the GPO applies, and then run the following command:
    gpupdate /force

 

Minimum recommended configuration for domain-joined computers

We recommend that all NETLOGON and SYSVOL shares be configured to require both mutual authentication and integrity in order to help secure Group Policy against spoofing and tampering attacks that can be leveraged to achieve remote code execution.

Hardened UNC paths

Value name Value
\\*\NETLOGON RequireMutualAuthentication=1, RequireIntegrity=1
\\*\SYSVOL RequireMutualAuthentication=1, RequireIntegrity=1

 

References:

 

(Visited 8,707 times, 9 visits today)

6 comments

Skip to comment form

    • Brad on February 12, 2015 at 11:01 am

    Since XP and 2003 will not be patched. What is the effect of implementing UNC Hardened Access on the SYSVOL and NETLOGON shares as recommended? Will the unpatched clients simply operate normally as I’d imagine?

    As I understand it, the real risks are for patched client machines that will obey the UNC Hardened Access settings but cannot full fill the policy requirements for mutal auth, integrity, or privacy because either the server or client doesn’t support it. So an SMB server that doesn’t support integrity or privacy like an old 2003 server would be inaccessible to a client that required it for instance. But I’m assuming if you have 2k3 R2 DCs you’ve got other issues…

    1. Post updated with Windows Server 2003 information.

    • Sander on February 13, 2015 at 5:14 am

    What ‘ll happen if you still have some server 2003 in your domain and/or linux clients? Can they still access those shares that are hardened with the GPO settings?

    1. Post updated with Windows Server 2003 information. Effectively, if the client supports the UNC hardening requirements, it will request higher level security.

      • Eric Chipko on February 16, 2015 at 9:45 pm

      Yes. They can access the shares as its a GPO that requires the “client or whatever computer is reading those shares” to do extra processing before processing.
      The sysvol and netlogon are unchanged themselves and only require the DC to Enable SMB signging if client and server negotiate for it. Require is still possible and may block those “clients”

    • Eric Chipko on February 16, 2015 at 9:42 pm

    Researching this one for legacy 2003 servers.
    If the SMB client side and server side on the DC, why is this not an effective workaround for the vulnerability.
    Assumes, of course, that MS15-014, is installed on the member server with SMB client signing enabled and will actually stick.

Comments have been disabled.