Abusing directory protocols to manipulate AD databases

Introduction

The Lightweight Directory Access Protocol (LDAP) is widely used to store and retrieve information about users, groups, computers and other directory objects. In enterprise environments, LDAP is particularly important because applications and systems may use it to authenticate users or retrieve information from services such as Active Directory.

LDAP poisoning & LDAP Injection

LDAP poisoning describes an attack in which an attacker manipulates LDAP-related communications or directory information so that systems or applications receive information that they should not trust.

The term is sometimes used broadly, but it is important to distinguish LDAP poisoning from LDAP Injection, where malicious input alters an LDAP query constructed by an application.

LDAP Injection occurs when an application incorporates untrusted user input directly into an LDAP query.

For example, an application might construct a search filter from a username supplied by a user. If the input is not properly escaped, an attacker may manipulate the LDAP filter and cause the application to perform a different search than intended.

This can potentially allow:

• Authentication bypass
• Unauthorised information disclosure
• Access to additional directory objects
• Modification of directory information
• Circumvention of application restrictions

OWASP identifies LDAP Injection as a server-side injection vulnerability caused by manipulating LDAP search, add or modify operations.

LDAP poisoning is a broader concept involving the manipulation or abuse of trusted LDAP information or communication.

Depending on the attack, this could involve:

• Manipulating directory entries
• Providing malicious LDAP responses
• Intercepting and altering LDAP traffic
• Abusing insecure LDAP authentication
• Redirecting LDAP-related requests
• Exploiting applications that implicitly trust directory information

One important example is LDAP entry poisoning, where malicious directory information can influence applications performing directory lookups.

LDAP Poisoning vs LDAP Injection

LDAP Poisoning	LDAP Injection
Broad term covering manipulation or abuse of LDAP trust	Specific application injection vulnerability
May involve directory data or LDAP communication	Primarily manipulates LDAP queries
Can involve interception or manipulated responses	Usually begins with malicious application input
Can affect applications and directory services	Primarily affects applications using LDAP
May involve MITM techniques	Similar concept to SQL Injection
Can contribute to authentication or authorisation abuse	Can cause authentication bypass or data disclosure

The distinction between these types of LDAP abuse is important because LDAP Injection is a well-defined vulnerability, whereas LDAP poisoning is used more broadly for several different LDAP trust-manipulation scenarios.

How LDAP poisoning works

The basic concept of LDAP poisoning is trust manipulation – An application or system expects LDAP to provide legitimate directory information, but if an attacker can influence that information, intercept LDAP traffic, or manipulate how an application constructs and processes LDAP requests, the attacker may be able to alter the behaviour of the system.

The exact technique depends heavily on the environment and vulnerability being exploited.

Why LDAP Is Attractive to Attackers

LDAP often sits at the centre of an organisation’s identity infrastructure. A compromised or manipulated directory interaction can therefore have consequences far beyond a single application.

LDAP may contain information relating to:

• User accounts
• Groups
• Computers
• Organisational units
• Email addresses
• Service accounts
• Access permissions
• Application configuration
• Authentication information

The more an application trusts LDAP, the greater the potential impact of a successful attack.

Common Attack Scenarios

1. Vulnerable LDAP Queries

An application constructs LDAP queries using unsanitised user input.

The attacker manipulates the input so that the resulting LDAP query performs an unintended operation.

This is the classic LDAP Injection scenario.

2. Manipulated Directory Information

If an attacker obtains sufficient privileges to modify directory objects, they may alter information that applications rely upon.

For example, an attacker might attempt to manipulate:

• Group membership
• User attributes
• Application-specific directory attributes
• Service configuration

The application may subsequently trust the modified information.

3. Intercepted LDAP Communication

LDAP traffic that is not adequately protected can potentially be exposed to interception or manipulation.

Microsoft notes that unsigned LDAP traffic is vulnerable to replay and man-in-the-middle attacks, because an attacker may intercept and modify traffic between a client and Domain Controller.

This is particularly significant in Active Directory environments where LDAP is used for authentication and directory operations.

Detecting LDAP Attacks

Organisations should monitor both LDAP activity and changes to directory objects.

Potential indicators of LDAP abuse include:

• Unusual LDAP search activity
• Unexpected authentication failures
• LDAP queries containing unusual filter characters
• Requests originating from unexpected systems
• Unexpected modifications to directory objects
• Changes to privileged group membership
• Unusual LDAP connections
• Authentication using unexpected accounts
• Unusual modification of directory attributes
• Unsigned LDAP connections where signing is expected

For applications, source-code review and application security testing can help identify LDAP Injection vulnerabilities. OWASP recommends examining how untrusted data is incorporated into LDAP queries and ensuring appropriate escaping is used.

Preventing LDAP Attacks

• Validate and Sanitise Input – Never allow untrusted input to become part of an LDAP query without appropriate validation and contextual escaping.
• Use Safe LDAP APIs – Applications should use APIs and frameworks that separate user-supplied data from LDAP query structure where possible.
• Apply Least Privilege – LDAP service accounts should have only the permissions they actually require.
• Protect LDAP Communications – Organisations should protect LDAP traffic against interception and manipulation.
• Use LDAP signing – In Active Directory, LDAP signing provides protection against unsigned LDAP communications, while channel binding can further protect authentication exchanges.
• Monitor Directory Changes – Changes to privileged accounts, groups and sensitive attributes should be monitored and investigated.
• Secure Active Directory Delegation – Directory permissions should be regularly reviewed to identify accounts that have unnecessary rights to modify sensitive objects.

Conclusion

LDAP is often trusted because it sits behind authentication, identity and access-control systems. An attacker who can manipulate LDAP queries, directory information or LDAP communication may be able to influence what applications and systems believe about users and permissions.

The most effective protection combines secure LDAP application development, proper input validation, least privilege, LDAP signing, encrypted communications and continuous monitoring of directory activity.

LDAP should never be treated as inherently trustworthy simply because it is part of the organisation’s identity infrastructure.