You may recall that in March 2020 Microsoft was planning to configure a couple of Lightweight Directory Access Protocol (LDAP) security settings on behalf of its customers. The company ended up not pulling the trigger, even though vulnerabilities still exist with the default implementation of LDAP. These security holes allow man-in-the-middle (MITM) attacks and replay attacks to occur.
Microsoft’s recommendations for securing LDAP settings are still applicable; however, most organizations have not acted. The reasoning for this seems to be multi-faceted, but the prevailing reason is that organizations have no idea what issues the recommended configurations will resolve or what the impact of these changes will be on the business—especially in case of any incompatible systems or configurations. In this blog post, we’ll start with the basics, explore the security issues, and discuss where to go next. Our hope is that this primer on LDAP security will dispel any fears you have and allow you to move forward.
The Background on LDAP
LDAP has a few variations of implementations. The implementation created by Microsoft is called Active Directory (AD). It defines how object information (such as users and computers) is stored in the directory. It’s also a communication channel where clients can query the AD database for objects such as groups, users, and computers.
LDAP clients authenticate to a domain controller (DC), which is an LDAP server. An LDAP client can authenticate with a password or some other credential, such as a Kerberos ticket. LDAP supports Simple Authentication and Security Layer (SASL) for LDAP binding, which employs the concept of abstracting the authentication mechanism from the communication protocol (in this case, LDAP).
When “bind” is used in the context of LDAP, its meaning is interpreted as LDAP authentication. When SASL binding is used, the LDAP client and LDAP server negotiate on the authentication protocol, such as Kerberos or NTLM. LDAP also supports simple authentication, which allows credentials to be transmitted in clear text—an obvious concern.
The default AD implementation does not prevent MITM attacks or replay attacks, where confidentiality and integrity would otherwise stop a bad actor in their tracks. Confidentiality and integrity are two of the three pillars in the CIA triad, with availability being the third pillar. The lack of confidentiality and integrity in the default AD configuration wasn’t so much of a problem when it was first introduced in Windows 2000. However, recon and attack tools such as LDAP Relay Scan and NTLMRelayX are exposing this oversight as a glaring problem.
Before you get started on LDAP, have Ravenswood perform an Active Directory Health Check to ensure proper configuration.
Solving the LDAP Integrity Problem
Without integrity, LDAP clients blindly trust an LDAP server’s response to a client query. To solve the integrity problem, LDAP signing must be implemented. Signing allows a recipient to validate that the sender is who they say they are, providing non-repudiation. LDAP signing doesn’t require any certificates to be issued. LDAP signing occurs when LDAP binding uses SASL. Some poorly developed LDAP clients lack the ability to perform LDAP SASL binds, which means only a simple LDAP bind can be used. By monitoring network traffic, a bad actor could obtain the username and password needed to establish new authentication tokens under the guise of a trusted user from which they can launch additional attacks. Although SASL negotiates on a security protocol for the credentials, which are likely encrypted using Kerberos or NTLM, LDAP signing alone does not mean the rest of the LDAP traffic is encrypted.
The good news is that in a Windows domain environment, you shouldn’t need to do anything to ensure LDAP signing is occurring. For a very long time now, all Windows clients are already configured by default to perform LDAP SASL binds. LDAP signing was introduced to clients running Windows 2000 Service Pack 4. All modern non-Windows devices should support LDAP signing as well, but it may be an option that requires configuration. In separate blog posts, we discuss how you can monitor for LDAP security and remediate LDAP security to fix LDAP integrity issues in your environment.
Solving the LDAP Confidentiality Problem
If a bad actor is monitoring your network traffic, they can acquire an otherwise unencrypted authentication token. To solve the confidentiality problem, a specially crafted encryption certificate must be installed on each DC. This allows LDAP clients to use the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) connection option to ensure communication is kept private between the sender and receiver, otherwise known as LDAP over SSL (LDAPS). If a bad actor captures an authentication token, they can perform any action that the credential is authorized for, which can be extremely dangerous. As an example, if an authentication token is acquired by a bad actor for a user who can update the Domain Admins group, an organization-wide attack becomes imminent.
Prior to DCs being issued a certificate for LDAPS, all clients send LDAP requests to port 389 on a DC (or port 3268 for the Global Catalog). Windows clients that use LDAPS send LDAP traffic to port 636 on DCs by default (or port 3269 for a Global Catalog), although they can use StartTLS, which is the preferred method for encrypting LDAP traffic. Even when Windows clients aren’t configured to use LDAPS, they are still binding securely by default because they are performing SASL binds. Most non-Windows devices have implemented StartTLS, which is just a command protocol rather than an encryption protocol. It uses ports 389 and 3268 for LDAP traffic but establishes a TLS tunnel before authentication information is exchanged. For this reason, ports 389 and 3268 should never be blocked on DCs. Microsoft does not support environments where these ports are blocked on DCs. In our earlier blog posts, we discuss how you can monitor for LDAP security and remediate LDAP security to fix LDAP confidentiality issues in your environment.
There’s One More Problem
To close the loop on the MITM and replay attacks on LDAP, there’s one more piece to the puzzle. LDAP channel binding tokens (CBTs) improve LDAP security by tying the transport layer together with the application layer, creating a unique identifier known as a thumbprint—or token—that is impossible to reuse. This is because a bad actor attempting an MITM or replay attack would be establishing a new TLS tunnel, which would be generating its own unique thumbprint and making those attack techniques useless. Since LDAP CBTs only secure the TLS tunnel of an LDAPS connection, regular (i.e., unencrypted) LDAP connections are not secured. For clients to take advantage of LDAP CBTs, DCs must have been previously issued an LDAP encryption certificate and the LDAP CBT functionality must be present in the LDAP client. Microsoft implemented this functionality retroactively back to Windows XP and Windows Server 2003 by introducing Extended Protection for Authentication (EPA) in 2009. Notably, this functionality has also been implemented in Red Hat Enterprise Linux (RHEL) 6, VMware products, Trend
Micro products, NetApp products, and many others. In previous blog posts, we discuss how you can monitor for LDAP security and remediate LDAP security to fix LDAP tunneling issues in your environment.
Summary
LDAP traffic contains sensitive information and can be abused in the wrong hands. Therefore, it’s important to protect LDAP data in transit. Keep integrity in place by enforcing LDAP signing, and implement confidentiality by configuring applications to use StartTLS or TLS explicitly. If you need help with LDAP security to harden your LDAP traffic, reach out to the experts at Ravenswood Technology Group. Contact us today!
