Understanding Windows Elevation of Privilege Vulnerability (CVE-2017-8563, LDAP & NTLM) + Helping Preempt With Active Directory Security

Folks,

This is VERY important, so you'll want to read it. It concerns a zero-day vulnerability in Windows brought to Microsoft's attention by a company called Preempt, that exploits a weakness in LDAP-S involving NTLM, which could result in elevation of privilege.

[ By the way, it's only Wednesday and its already been a busy week - I was going to pen Day-10 of our Active Directory Security school for Microsoft on Sunday night, but instead had to pen a letter to President Trump in light of his tweet. Then I was going to pen it yesterday, but in light of this vulnerability, I had to pen this to help everyone easily understand this, and to help Preempt. ]




A Short Summary of This Vulnerability

Folks, in the interest of everyone's time, I'm not going to repeat all the details in-depth. You can find them here, here and here.

In short, there exists a vulnerability in LDAP-S that permits the enactment of an NTLM relay attack, and in effect could allow an individual to effectively impersonate a(n already) privileged user and enact certain LDAP operations to gain privileged access.

Very Important: The term "privileged user" is often loosely used and misconstrued, so its imperative to understand that here a privileged user refers to any domain user account that has privileged access in Active Directory.

The simple, key thing to understand here is that since the vulnerability exists in Microsoft's implementation of LDAP-S, LDAP being the protocol used to access and manage Active Directory content, its primary target ends up being Active Directory content, and since it involves exposure to NTLM relay attacks, Active Directory privileged users are prime victim candidates.

To describe this simply, if a user that possesses privileged access in Active Directory authenticates using NTLM to a machine owned by a perpetrator, the perpetrator could exploit this vulnerability in LDAP-S to enact an NTLM relay attack in which he/she would impersonate the privileged user('s account) to Active Directory, then just enact a few LDAP operations in that privileged user's security context to obtain a separate authenticable account that would now possess privileged access in Active Directory.




A Simple Example

Here's an example. Imagine that you are a Domain Admin, so obviously to begin with you have God-like powers within Active Directory itself (and by extension everywhere, but that's not important here), and so of course you can do things like create new user accounts in Active Directory, modify group memberships including those of privileged groups such as Domain Admins.

Now, lets assume you're logged in using our Domain Admin account and you happen to access a Share point portal that resides on a machine owned by the perpetrator (think intruder.) In that simple act, if the machine could have the authentication involved be downgraded to NTLM, then...

• Firstly, that very moment, malicious code running on that machine would attempt to and successfully impersonate you to a Domain Controller, thus ending up having a network logon session as you on a Domain Controller, & then ...
• Secondly, since it now has successfully authenticated to a Domain Controller as you, it could now enact a simple LDAP operation (create object) to create a new user account with a password of the perpetrator's choice, followed by another simple LDAP operation (modify object) to add that newly created account to the Domain Admins group.

That's it! All of this would happen very quickly (almost instantaneously) and so transparently to you that you wouldn't even notice, and within seconds the perpetrator would now have a new user account that also has Domain Admin privileges!




A Small Suggestion (and Active Directory Security 102) For Preempt

I'm sure we are all thankful to Preempt for discovering this vulnerability and bringing it to Microsoft's attention, which led to Microsoft releasing a patch for it today. That said I do have some helpful reading and a small suggestion for Preempt -

Here's how Preempt describes the potential impact of this risk (source) -

"As a result, every connection of an infected machine (SMB, WMI, SQL, HTTP) with a domain admin would result in the attacker creating a domain admin account and getting full control over the attacked network."

My suggestion to them would be to perhaps consider making the following modification to their description -

"As a result, every connection of an infected machine (SMB, WMI, SQL, HTTP) with any domain user account that has sufficient privileged access (i.e. Active Directory effective permissions) to enact any one the following tasks (all of which merely involve LDAP operations) in Active Directory could result in the attacker potentially obtaining full control over the attacked network."

1. Use Mimikatz DCSync to replicate secrets from Active Directory
2. Modify permissions in the ACL protecting the Domain root object
3. Reset the password of any one Active Directory privileged user account
4. Modify the membership of any one Active Directory privileged group
5. Modify permissions in the ACL protecting the AdminSDHolder object's ACL
6. Modify gpLink and gpOptions attributes on the default Domain Controllers OU
7. Modify critical Active Directory configuration content or the Schema
8. Establish an incoming forest trust or an external trust with domain

+


9. Create a user account (; this is optional AND it is only required if the perpetrator does not already have either his/her own or control over someone else's domain user account)

Here's why. To exploit this vulnerability and gain full control over the network, you don't need to be a Domain Admin. You only need sufficient privileges (i.e. effective permissions / effective access) in Active Directory to enact any one of the above tasks.

In the foundational Active Directory deployments of most organizations, you'll find that there are many many more accounts that can actually enact any, some or all of the admin tasks (i.e. LDAP operations) listed above than the number of Domain Admins!

Hopefully you can now see why it is so vital to know at all times, exactly who can enact each of these tasks in Active Directory.




How to Mitigate This Vulnerability

To mitigate this vulnerability, ensure that all systems are patched and up to date as of July 11, 2017. Specifically, you'll want to ensure that the update for CVE-2017-8563 is installed. In addition, to make LDAP authentication over SSL/TLS more secure, admins will need to create a LdapEnforceChannelBinding registry setting on a Domain Controller (; Microsoft KB 4034879.)



A Few Interesting Observations

Before I conclude this post, I'd like to share a few observations that I think you'll find interesting -

1. Is it just me, or do you too find it so very interesting that this is the second time that a major vulnerability in Windows authentication protocols has been found by a company in the business of building behavioral firewalls?! I suppose they need to find such smoking guns to validate the need for their products, and they seem go to great lengths to do so.


2. I care deeply for Microsoft, but I'll say this again - how come start-ups funded to the tune of a few million $ can find such vulnerabilities in Windows, whereas a $ 550 Billion behemoth (Microsoft) is not able to find them on its own?


3. What is going to take to make organizations and vendors realize that Domain Admins are merely the Tip of the Iceberg? There are so many more accounts that also posses a substantial amount of excessive privilege in Active Directory?


4. Why can't organizations accomplish something as simple as a) minimizing the number of privileged users in their Active Directory and b) creating and enforcing a simple policy that such users are only to logon to admin workstations and DCs?


5. In light of this and this, how can organizations not yet know how to correctly audit privileged access in Active Directory?

That's it for today.

Best wishes,
Sanjay.