Written by: Matthew Burns
What is LDAP?
Microsoft states that Lightweight Directory Access Protocol (LDAP) is, “a directory service protocol that runs on a layer above the TCP/IP stack. It provides a mechanism used to connect to, search, and modify Internet directories.” LDAP is a protocol that allows for Active Directory to be modified or queried for information. LDAP accomplishes this by storing data in an LDAP directory or database. To access this data an active directory user will need to successfully authenticate to the server with the LDAP database. LDAP over SSL (LDAPS) also exists which is the same protocol as LDAP just with encryption enabled through Secure Sockets Layer (SSL).
Why is LDAP Dangerous?
LDAP is dangerous for one main reason – it accepts New Technology LAN Manager (NTLM) based authentication. This means that without any hardening steps the default configuration for LDAP on domain controllers will be vulnerable to an NTLM relay attack. Normally, an LDAP relay can only be used to enumerate information from the domains such as users, groups, password policy, and more. However, this can get scary if LDAPS is enabled.
If LDAPS is enabled an attacker can use the relay attack to gain a foothold in the domain by adding a machine account. This is possible because, by default, any domain user in the authenticated users group can add up to ten machine accounts to the domain, which is a separate problem on its own. Below is an example of this attack being performed using Impacket’s Ntlmrelax tool:
Once a machine account is added to the domain the attacker now has an account in the domain, since they will know the password of the machine that they added. Once a foothold is established an attacker can do any number of things such as move laterally, enumerate other computers, or even escalate their privileges. Escalating privileges can be done through a variety of means, for example, with an account an attacker can coerce the authentication from the Domain Controller using PetitPotam.
The domain controller hash can be used with Active Directory Certificate Web Enrollment Services if they are enabled in the domain. The domain controller hash from PetitPotam can be relayed to the Web Enrollment endpoint to generate a certificate for the domain controller. This certificate can then be used to easily compromise the domain. A more in-depth write-up of this attack can be found in my previous blog post.
It is safe to say if LDAP is not properly hardened it can be a playground for attackers.
How to Harden LDAP
The first step to hardening LDAP is to enable LDAP channel binding. This helps to secure LDAPS by forcing all clients trying to connect to the LDAP server to successfully authenticate. Once authentication is successful, the LDAP server then binds together (hence the name channel binding) the LDAP protocol and SSL/TLS channel used to create the LDAP connection. Once they are bound together the connection has a unique fingerprint. If the LDAPS connection were to be relayed by an attacker a new TLS connection would need to be established meaning the unique fingerprint would no longer match, invalidating the LDAPS connection.
However, LDAP channel binding on its own can be bypassed by attackers during relay attacks. If StartTLS is configured in the domain and only channel binding is enabled, then an attacker can still use the LDAPS protocol. This is done by an attacker by first relaying a normal LDAP connection and then using StartTLS to upgrade the connection to LDAPS. More information on how this attack works can be found here. That is why it is important to also secure the LDAP protocol with signing.
The second and most important step to hardening LDAP is to enable LDAP signing. LDAP signing is the same concept as SMB signing, so each LDAP message will contain a hashed signature. This hash is generated using the session key of the client. This means that if an attacker tries to relay an LDAP message for authentication, while LDAP signing is enabled, the signature hash will not match, making the LDAP authentication attempt fail. This works for both LDAP and LDAPS.
Microsoft has released guidance that states that enabling LDAP channel binding and LDAP signing will remediate LDAP relay attacks and we have also seen during our penetration tests that the settings recommended by Microsoft are effective in mitigating LDAP attacks.