Last Tuesday, during Microsoft’s July 2017 Patch Tuesday, Microsoft released a security update for all supported Operating Systems to address an elevation of privilege vulnerability that exists when Kerberos falls back to NT LAN Manager (NTLM) Authentication Protocol as the default authentication protocol.
About the vulnerability
In a remote attack scenario, an attacker could exploit this vulnerability by running a specially crafted application to send malicious traffic to an Active Directory Domain Controller. An attacker who successfully exploited this vulnerability could run processes in an elevated context. There is a good explanation of the vulnerabilities at the Preempt blog. Preempt also offers a video where they demonstrate the attack vector.
The update addresses this vulnerability by incorporating enhancements into Extended Protection for Authentication. These enhancements are designed to mitigate authentication attacks. It revolves around the concept of channel binding information.
When Extended Protection for Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server the client attempts to connect to and to the outer Transport Layer Security (TLS) channel over which the Integrated Windows Authentication (IWA) authentication takes place.
About the update
Microsoft issued the following update packages:
|Windows 10||4025338||Security update|
|Windows 10 v1511||4025344||Security update|
|Windows 10 v1607||4025339||Security update|
|Windows 10 v1703||4025342||Security update|
|Windows 7 with Service Pack 1||4025341||Monthly Rollup|
|Windows 8.1||4025336||Monthly Rollup|
|Windows Server 2008 with Service Pack 2||4025409||Security update|
|Windows Server 2008 R2 with Service Pack 1||4025341||Monthly Rollup|
|Windows Server 2012||4025331||Monthly Rollup|
|Windows Server 2012 R2||4025336||Monthly Rollup|
|Windows Server 2016||4025339||Security update|
Updates need to be installed on all systems within the networking environment to enable the channel binding enhancements.
Active Directory Domain Controllers
The security update that is described in CVE-2017-8563 introduces a registry setting named LdapEnforceChannelBinding, leveraging the Extended Protection for Authentication functionality in Windows’ Security Support Provider Interface (SSPI).
Active Directory admins can use this registry setting to help make LDAP authentication over SSL/TLS more secure.
To enable this functionality, Active Directory admins need to explicitly configure the following registry setting on all their Active Directory Domain Controllers, after they installed the corresponding update:
- Path: HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/NTDS/Parameters
- Setting (Name): LdapEnforceChannelBinding
- DWORD value: 0 indicates disabled. No channel binding validation is performed. This is the behavior of all servers that have not been updated.
- DWORD value: 1 indicates enabled, when supported. All clients that are running on a version of Windows that has been updated to support channel binding tokens (CBT) must provide channel binding information to the server. Clients that are running a version of Windows that has not been updated to support CBT do not have to do so. This is an intermediate option that allows for application compatibility.
- DWORD value: 2 indicates enabled, always. All clients must provide channel binding information. The server rejects authentication requests from clients that do not do so.
Server Core installations of Windows Server are vulnerable to this attack vector and need to be updated, too.
Admins need to restart the Operating System to apply the update. However, admins do not have to restart their Domain Controllers a second time to apply the above registry change.
Microsoft has not identified any mitigating factors for this vulnerability.
Microsoft has not identified any workarounds for this vulnerability.
The vulnerability was responsibly disclosed three months ago to Microsoft by Yaron Zinar, Eyal Karni, and Roman Blachman at Preempt.
Call to action
I urge Active Directory admins to apply the update throughout their networking environment, following their normal test procedures.
Since Domain Controllers are under more strict control than client devices, the recommended way to implement this functionality is to update the Domain Controllers and set the LdapEnforceChannelBinding registry value to 1.
Then, when you’ve updated all the client devices in scope, set the LdapEnforceChannelBinding registry value to 2.
Do not change the value to 2 when you have Windows Vista or Windows Server 2008-based installations. This is a known issue as described in KnowledgeBase article 979231.
Extended Protection for Authentication
CVE-2017-8563 | Windows Elevation of Privilege Vulnerability
Microsoft Patch Tuesday – July 2017
Windows NTLM fix addressed in July 2017 Patch Tuesday
Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure
How-To: Use LDAP Over SSL to Lock Down AD Traffic
LDAP over SSL/TLS: How secure is your Directory?
Understanding Windows Elevation of Privilege Vulnerability (CVE-2017-8563)
New LDAP & RDP Relay Vulnerabilities in NTLM
[VIDEO] LDAP & RDP Relay Vulnerabilities in NTLM – Demonstration
Could you please help me understand something? In the registry if the "folders" are called keys/sub-keys and the DWORD is a value type, where does the LdapEnforceChannelBinding go?
Do I create a new "folder" key called LdapEnforceChannelBinding under HKLM…/Parameters, then add a DWORD? What do I name the DWORD? OR is the LdapEnforceChannelBinding the name of the DWORD inside …/Parameters?
The lingo in the Windows Registry is a bit confusing, yes.
The Registry has keys. These are depicted in the Registry Editor as folders.
Then there are values. These appears as files.
There are multiple types of values: STRING, BINARY, DWORD, etc.
Values can have data. The data, most of the times, enables or disables functionality.
The LdapEnforceChannelBinding value ('file') of DWORD type should be manually created in the Parameters key ('folder').
Then, its data should correspond with the functionality you desire.
Any thoughts on how this setting could impact open source systems connecting via LDAPS?
Yes, non-windows system may not be compatible with creating this value and setting it to anything else than 0. We have some in our environment
I would expect if I set this LdapEnforceChannelBinding DWORD to 2, that a cleartext LDAP BIND on port 389 would not be allowed. But it is. What am I doing wrong?
I can confirm that DIGEST-MD5 (SALS) and simple Binds over TLS still work when the =2 value is set. It looks like it is only enforcing this for GSS-SPNEGO and GSSAPI SASL logins. Am I right?
Apparently the key registry keys are not documented on https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry completely. One must also follow the instructions at https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008. In short the keys also need modified to set the Value data to 2 for the ldapclientintegrity DWORD:
The above information was the information that Microsoft made available in 2017.
Back then, improving LDAP Channel Binding was deemed an appropriate scope for remediation.
Today, we take LDAP Signing as a requirement into scope as well.
However, to manually set Microsoft's LDAP Signing changes, you'd configure the LdapServerIntegrity key, not LdapClientIntegrity.
See my blogpost on these changes for LDAP Token Binding and LDAP Signing for more information.