What is LDAP Injection? Ways to Exploit, Examples and Impact

In the modern enterprise landscape, managing users, permissions, and organizational resources requires a centralized and efficient system. The Lightweight Directory Access Protocol (LDAP) has been the industry standard for this task for decades. However, like any protocol that handles user-supplied data to construct queries, it is susceptible to injection attacks. LDAP injection is a critical vulnerability that allows attackers to manipulate directory queries, potentially leading to unauthorized access, data theft, or even full administrative control over an organization's identity infrastructure.

Understanding the Lightweight Directory Access Protocol (LDAP)

Before diving into the mechanics of the injection itself, it is essential to understand what LDAP is. LDAP is a client-server protocol used to access and manage directory information. Think of a directory as a specialized database optimized for reading, searching, and browsing rather than complex transactional updates. It typically stores information about users, groups, devices, and organizational units in a hierarchical structure known as the Directory Information Tree (DIT).

LDAP is most commonly used for authentication (verifying who a user is) and authorization (verifying what a user can do). For example, when you log into a corporate VPN or a web portal using your employee credentials, the application likely sends an LDAP query to a server like Microsoft Active Directory or OpenLDAP to verify your username and password.

What is LDAP Injection?

LDAP injection occurs when a web application or service takes user-supplied input and includes it in an LDAP query without proper sanitization or filtering. By providing specially crafted input, an attacker can alter the logic of the query. Because LDAP queries use a specific syntax involving logical operators and wildcards, an attacker can "break out" of the intended query structure to execute their own commands.

This vulnerability is conceptually very similar to SQL Injection. While SQL Injection targets relational databases, LDAP injection targets directory services. The goal is often the same: to bypass authentication mechanisms or extract sensitive information that should otherwise be restricted.

The Syntax of LDAP Queries

To understand how to exploit LDAP, you must understand how queries are built. LDAP uses a prefix notation (also known as Polish notation), where the operator precedes the operands. The most common logical operators are:

• & (AND): All conditions must be true.
• | (OR): At least one condition must be true.
• ! (NOT): The condition must be false.
• * (Wildcard): Matches any value.

A typical query to find a user might look like this:
(&(uid=jdoe)(objectClass=person))

In this query, the server looks for an entry where the uid is "jdoe" AND the objectClass is "person". If an application allows a user to provide the uid value directly, that is where the injection point lies.

How LDAP Injection Works: A Technical Breakdown

Imagine a web application that has a search feature to find employee phone numbers. The backend code might look something like this (in a simplified pseudo-code format):

$username = $_GET['user'];
$query = "(&(uid=" . $username . ")(objectClass=person))";
$results = $ldap->search($query);

If a legitimate user searches for "alice", the query becomes (&(uid=alice)(objectClass=person)). This works as intended. However, if an attacker provides a malicious input, they can change the entire meaning of the search.

1. Authentication Bypass

Authentication bypass is the most dangerous form of LDAP injection. Suppose a login page uses the following query to verify credentials:

(&(user=$user)(password=$pass))

If the attacker enters admin as the username and *)(|(password=* as the password, the resulting query becomes:

(&(user=admin)(password=*)(|(password=*))

In many LDAP implementations, the * wildcard in the password field matches any value. More importantly, by injecting closing parentheses and new logical blocks, the attacker can force the query to return "True" regardless of the actual password. If the LDAP server returns a valid user object, the application assumes the login was successful.

2. Information Disclosure and Attribute Discovery

Attackers can also use injection to map out the directory structure. By using the wildcard character *, an attacker can discover valid usernames or other attributes.

For example, if an attacker provides a* in a search field, the query might become (uid=a*). The server will return all users starting with the letter 'a'. By iterating through the alphabet, the attacker can compile a complete list of users. This is a vital step in the reconnaissance phase of a larger cyberattack.

Furthermore, an attacker can use injection to reveal hidden attributes. If the application only displays the "Common Name" (cn), but the query is vulnerable, the attacker might inject code to filter for specific roles, such as (employeeType=Executive). This allows them to identify high-value targets within the organization.

3. Blind LDAP Injection

Sometimes, the application does not display the results of the LDAP query directly. It might only return a generic "User Found" or "User Not Found" message. This is known as Blind LDAP Injection. Even in this scenario, an attacker can extract data bit by bit using Boolean logic.

An attacker might ask the server: "Does the admin user's password start with the letter 'A'?"
Input: admin)(password=A*
If the application says "User Found," the attacker knows the first letter is 'A'. If it says "Not Found," they try 'B', and so on. This process can be automated with scripts to dump entire databases over time.

Real-World Impact of LDAP Injection

The consequences of a successful LDAP injection attack can be devastating for an organization. Because LDAP often sits at the heart of identity and access management (IAM), a compromise here can ripple through the entire network.

• Unauthorized Access: Attackers can log into internal systems, email accounts, and cloud environments by bypassing authentication.
• Data Exfiltration: Sensitive employee data, including home addresses, phone numbers, social security numbers, and organizational hierarchies, can be stolen.
• Privilege Escalation: By manipulating group memberships or discovering administrative accounts, an attacker can elevate their privileges to gain control over the domain.
• Infrastructure Mapping: LDAP contains a wealth of information about the network's assets. Attackers use this to identify servers, printers, and other connected devices for further exploitation.

How to Detect LDAP Injection Vulnerabilities

Detecting LDAP injection requires a mix of manual testing and automated tools. For security professionals and developers, the following methods are effective:

1. Fuzzing: Input special characters like (, ), &, |, *, and ! into form fields. If the application returns an LDAP error message or behaves unexpectedly (e.g., returning more results than requested), it is likely vulnerable.
2. Static Analysis (SAST): Review the source code for instances where user input is concatenated directly into strings used for LDAP queries. Look for functions like ldap_search or LdapConnection.Search and trace the origin of their parameters.
3. Dynamic Analysis (DAST): Use web vulnerability scanners that specifically test for injection flaws. These tools will automatically attempt various LDAP payloads and analyze the responses.

Prevention: How to Secure Your LDAP Queries

Preventing LDAP injection follows the same fundamental principles as preventing other injection attacks: never trust user input.

1. Use Parameterized Queries or Frameworks

Modern programming libraries often provide safe ways to build LDAP queries. Instead of manual string concatenation, use built-in functions that handle the encoding of special characters automatically. For example, in .NET, use the DirectorySearcher class with properly defined filters rather than building a raw string.

2. Input Validation and Sanitization

If you must build queries manually, implement strict input validation. Define a whitelist of allowed characters (e.g., alphanumeric only) and reject any input that contains LDAP special characters like (, ), *, and \.

If special characters are required for legitimate use, they must be escaped. In LDAP, escaping is done by replacing the character with a backslash followed by its two-digit hexadecimal ASCII representation. For example:

• * becomes \2a
• ( becomes \28
• ) becomes \29
• \ becomes \5c

3. Principle of Least Privilege

Ensure that the service account used by the web application to connect to the LDAP server has the minimum permissions necessary. It should only have read access to the specific branches of the DIT required for its function and should never have administrative rights over the directory.

Conclusion

LDAP injection remains a potent threat because many developers overlook directory services when securing their applications. By understanding the prefix notation of LDAP queries and the power of logical operators, attackers can easily bypass security controls if input is not handled correctly. Securing your infrastructure requires a proactive approach, combining robust coding practices with continuous monitoring of your external environment.

To proactively monitor your organization's external attack surface and catch exposures before attackers do, try Jsmon.