A Pentester Guide to LDAP Bind Method Vulnerabilities

Lightweight Directory Access Protocol (LDAP) provides a convenient standard for distributed directory service collaboration, but its authentication methods have known vulnerabilities. The LDAP Bind command blocks some attacks, but it can be bypassed when anonymous authentication is allowed.

In this pentester guide, we'll provide an overview of LDAP Bind methods and their vulnerabilities. We'll cover:

• What LDAP is?
• How LDAP is vulnerable to LDAP injection?
• How Bind authentication can be bypassed and how to test for vulnerabilities?

What Is LDAP?

Lightweight Directory Access Protocol is a simplification of Directory Access Protocol (DAP), that provides a standard for accessing distributed directory environments where data is partitioned over multiple servers. 

Each server has its own namespace and potentially its own governing authority. Proxy servers coordinate requests and responses, enabling clients to interact with the distributed directory as if it were a single directory. Backend LDAP servers store and retrieve data to support request responses from users, including users and user groups defined over multiple servers.

LDAP servers typically store usernames, passwords, and other identifying information. Applications and services can connect to LDAP servers to authenticate and authorize users.

Various servers, platforms, and applications support LDAP authentication, including:

• Docker
• Jenkins
• Kubernetes
• Linux Samba
• OpenVPN

Network administrators frequently use LDAP for a single sign-on (SSO) feature to manage data access.

Companies may use LDAP for storing sensitive records such as:

• Corporate and customer email directories
• Telephone directories
• Printer connections

The sensitive nature of these records makes securing LDAP servers a high priority.

LDAP Injection

LDAP servers face vulnerability to a counterpart of SQL injection known as LDAP injection. In this vulnerability, attackers exploit LDAP's use of special characters in queries, notably:

• AND “&”
• OR “|”
• NOT “!”
• =
• >=
• <=
• ~=

These and other specified characters such as brackets and asterisks define the meaning of LDAP queries. If attackers can submit these characters without data validation and sanitization, they can change queries and execute undesirable commands that allow unauthorized permissions or alter content.

To illustrate, consider this LDAP filter request for an LDAP node with a given username and password:

Without data sanitization and validation, an attacker can potentially input * as the username and password to request a list of all users.

LDAP injections come in several varieties, including:

• Access control bypass: The attacker inputs a valid username and sequence into the username filter to automatically return a value of true, bypassing the password filter.
• Privilege escalation: The attacker inputs an access security level filter that is always true, listing all documents visible to users of all security levels.
• Information disclosure: The attacker inputs a user ID filter that is always true, listing all user objects.

Attackers can deploy these methods by directly entering operators or by indirectly leveraging error messages to obtain necessary information for launching injections.

LDAP Injection Mitigation

Security teams have developed best practices for mitigating LDAP injection attacks, including:

• Applying data validation and sanitization to prevent input of restricted characters from the list above:

• AND “&”
• OR “|”
• NOT “!”
• =
• >=
• <=
• ~=
• Use the LDAP library to construct strings containing user input rather than concatenating filters.Use access control to enforce least privilege when assigning user permissions
  Restrict searches by setting base distinguished name (base DN) and search scope
• Setting size limits for number of results returned by searches
• Restricting search processing time by setting timeouts
• Configuring the LDAPBIND command to authenticate users

While these security measures will prevent many LDAP injection attacks, they can be circumvented. One way to bypass them is by exploiting a vulnerability in the LDAPBIND command.

Common Exploit Path of LDAP Server Bind

This exploit leverages optional settings in the LDAPBIND authentication command that allow authentication of anonymous users. 

This functionality should be protected with sufficient safeguards or it should be disabled. Pentesters will test this vulnerability by checking for LDAP injection risk in search filters and login procedures.

LDAPBIND Command Anonymous Bind Functionality

The bind command sets an LDAP session's authentication state and protocol version. LDAP is currently on LDAPv3. LDAPv2 required the bind operation to start a session. LDAPv3 does not require this, but allows LDAPBIND to change a session's authentication state upon a successful bind and to reset it upon an unsuccessful one.

LDAPBIND may be deployed in multiple ways. Most commonly, LDAP uses simple bind authentication, also known as password-based authentication. Simple bind authentication allows a couple of methods of authenticating users:

• When the server should allow users to view content without providing a password, BIND can allow an empty DN field, enabling an anonymous and unauthenticated authentication state.
• When users should provide a password, BIND can require a DN and password.

Besides simple binds, binds also can use SASL authentication and certificate-based authentication.

The anonymous bind feature serves uses such as simplifying applications of search and read operations. For instance, users can search email or telephone directories without authenticating. However, this functionality creates a vulnerability.

Anonymous Bind Vulnerability and Mitigation

Attackers can bypass BIND authentication by exploiting the anonymous bind and unauthenticated bind options. Bad actors can use this to trigger buffer overflows causing denial of service as well as buffer overflows allowing arbitrary code execution.

Security teams have developed two main strategies to mitigate LDAP anonymous bind vulnerabilities:

• Disabling anonymous bind
• Alternately, configuring access control instructions to cap resource limits

Along with these measures, LDAP logs should be monitored for bind exploits.

Disabling Anonymous Bind

When anonymous bind is not needed, authentication can be required and anonymous bind functionality can be disabled by:

• Turning off the nsslapd-allow-anonymous-access configuration parameter:
  # dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-allow-anonymous-access=off
• Restarting the instance:
  # dsctl instance_name restart
  

Configuring Access Control Instructions to Cap Resource Limits

If anonymous bind is required, access control instructions (ACIs) should be configured to cap resource limits. This can be done by building a template user entry with resource limitations and applying it to anonymous blinds. To do this, first create a template, such as:

# ldapadd -D "cn=Directory Manager" -W -p 500 -h server.example.com -x
dn: cn=anonymous_template,ou=people,dc=example,dc=com
objectclass: nsContainer
objectclass: top
cn: anonymous_template
nsSizeLimit: 125
nsLookThroughLimit: 500
nsTimeLimit: 30

Point to the template entry DN for all suppliers in a replication topology by adding the nsslapd-anonlimitsdn parameter to the server configuration, in this fashion:

# dsconf -D "cn=Directory Manager" ldap://server.example.com config replace nsslapd-anonlimitsdn="cn=anonymous_template,ou=people,dc=example,dc=com"

Pentesting Anonymous Bind Vulnerabilities

Pentesters can take the following steps to test for LDAP anonymous bind vulnerabilities:

1. Discover the LDAP server: Use Nmap to identify LDAP server port 389.
2. Connect with anonymous bind: Establish an anonymous session without supplying credentials by running: ldapsearch -x -H ldap://<LDAP_SERVER> -b "<BASE_DN>"
3. Submit LDAP queries: Test for LDAP injection vulnerabilities by submitting queries.
4. Review results: Analyze test data to assess vulnerability.

When submitting LDAP test queries, pentesters can use input validation testing for LDAP injection vulnerabilities such as search filter and login vulnerabilities. For instance, an application may use search filters such as:
searchfilter="(cn="+user+")"

This might be instantiated by HTTP requests in a format such as:
http://www.example.com/ldapsearch?user=Mike

The value Mike can be replaced by an asterisk *:
http://www.example.com/ldapsearch?user=*

This will make the filter:
searchfilter="(cn=*)"

The result will match every object with a ‘cn’ attribute equaling any value.

If a vulnerability is present, the result will display some or all of the user’s attributes, depending on the user's permissions and the app's execution flow.

Similarly, pentesters can test for login vulnerabilities by checking for LDAP queries that yield results that are always true. For instance, say an application uses a filter to match an LDAP user's user/password pair:
searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";

Now say these values are entered:
user=*)(uid=*))(|(uid=*
pass=password

This will yield the results:
searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

This result is correct and always true, enabling the pentester to log in as the first user in the LDAP directory tree.

Testers should test vulnerabilities using multiple characters to define parameters, including (, |, &, *, etc. Security teams can deploy Dynamic Application Security Testing (DAST) to scan for LDAP injection risks automatically.

Test for LDAP Bind Vulnerabilities with Cobalt Pentesting

LDAP bind vulnerabilities can cause tremendous damage, but fortunately, they are easy to test for and mitigate. An LDAP bind pentest should form part of a comprehensive test for LDAP injection risk.

Penetration testing service empowers your security team to identify LDAP-related vulnerabilities and prioritize remediation accordingly. Our user-friendly platform lets you connect with the Cobalt Core, a highly-vetted group of experienced pentesters.

Contact Cobalt to schedule a demo or set up a test of your LDAP network's vulnerabilities with Agile Pentesting.