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
Recent Comments