MEMCM: Fixing MS15-011 Vulnerability in Group Policy that could allow remote code execution, using Compliance Settings in ConfigMgr

For past couple of months, I have been working on a vulnerability assessment project and as part of the exercise, I came across a vulnerability related to MS15-011: Vulnerability in Group Policy could allow remote code execution, that was flagged up on many servers. Nothing unusual about it and is easily fixable as long as you dot all the i’s and cross all the t’s. Nonetheless, I wanted to blog my experience in an endeavor to make it easier for others to implement this, should you choose to follow the method as documented below.

What is ‘MS15-011: Vulnerability in Group Policy could allow remote code execution’ all about? According to official documentation by MS,

A remote code execution vulnerability exists in how Group Policy receives and applies connection data when a domain-joined system connects to a domain controller. An attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs, could view, change, or delete data, or could create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.

The severity of this vulnerability is rated as Critical and understandably so. While there are multiple ways of fixing this, one obvious method being the GPO, I chose to use ConfigMgr compliance settings instead. This would also allow me to perform reporting on the compliance for the fix.

Solution:

After making sure that both the required updates ie. 3000483 and 3004375 were installed (Tip – You can roll out a compliance setting to check for the hotfixes as well), there were some additional registry settings that need to be rolled out in order to fix the vulnerability. You can read all about it here and choose the settings that suit your environment as this involves hardening the UNC paths.

Due to the complexity involved in configuring the vaules, it was decided with the customer to roll out the minimum recommended configuration for domain-joined computers. 

Since the registry settings are string values, I couldn’t use the built-in feature in the compliance settings of enabling the option for creating a registry against non-compliance rules. This is because the option only works for integer (REG_DWORD) type.

 

To get around this, one can use powershell scripts to discover and remediate at the same time. There may be other methods available within ConfigMgr, but I find this the simplest way to do it.

The discovery script I used is as follows –

For \\*\NETLOGON

 If (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths' -Name \\*\NETLOGON)

{ 

    Write-Output 'Compliant'

 } Else {

     Write-Output 'NonCompliant'

 } 

For \\*\SYSVOL

    If (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths' -Name \\*\SYSVOL)

{

     Write-Output 'Compliant'

 } Else {

     Write-Output 'NonCompliant'

 }

The remediation script that I used is as follows –

For \\*\NETLOGON

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\NETLOGON" /d "RequireMutualAuthentication=1, RequireIntegrity=1" /t REG_SZ

For \\*\SYSVOL

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\SYSVOL" /d "RequireMutualAuthentication=1, RequireIntegrity=1 " /t REG_SZ

Once created, the compliance setting will need to be set with condition equal to ‘Compliant’ and remediation enabled against noncompliant rules.

 

A baseline needs will need to be created containing the CI and can then be assigned to the intended collection. Don’t forget to enable the remediation and allowing it to run outside MW, incase you have them configured in your environment and you want the baseline to run outside the MW.  

End result:

After the policy was evaluated, the settings were applied as expected and the compliance was reported back to ConfigMgr. Do note that for this registry change to come into effect, a reboot will be required.

Happy days..