LDAP - Authentication Bypass

Now that we have a basic idea about how LDAP search filters work let us start with LDAP injection. A basic example of LDAP injection is bypassing web authentication. As discussed in the previous section, LDAP is commonly used to enable the authentication of AD users in web applications. Therefore, many web applications support LDAP authentication.

Foundation

Before discussing the exploitation of LDAP injection to bypass web authentication, let us first discuss what a search filter used for authentication may look like. Since the authentication process needs to check the username and the password, an LDAP search filter like the following can be used:

(&(uid=admin)(userPassword=password123))

Depending on the setup of the directory server, the actual search filter might query different attribute types. For instance, the username might be checked against the cn attribute type.

Exploitation

When starting the lab below, we can see a simple web application that implements a login process integrated with an OpenLDAP server:

Since the web application tells us about the LDAP integration, let us think of what we can inject into the search filter to bypass authentication. Because an asterisk is treated as a wildcard character, we can inject it into the password field to match the value without specifying the actual password. We can then specify an arbitrary valid username to bypass authentication for that user. If we specify a username of admin and a password of *, the web application executes the following LDAP search filter:

(&(uid=admin)(userPassword=*))

Sending the request, we can see that the backend redirects us to the post-login page, indicating that we successfully bypassed authentication and logged in as the user admin:

If we do not know a valid username, we could inject a wildcard into the username field as well, resulting in the following LDAP search filter:

(&(uid=*)(userPassword=*))

This search filter matches all entries with uid and userPassword attributes, thus matching all existing users. In this case, we are most likely going to log in as the first user in the list of results:

Lastly, if we only know a substring of a valid username, for instance, in a case where admin usernames are obfuscated by appending random characters, we can specify a substring in the username field to narrow down the list of results with a search filter like the following:

(&(uid=admin*)(userPassword=*))

This search filter matches all entries that contain a uid field starting with the string admin, thus bypassing the obfuscation described above, leading to a successful login bypass for the admin user:

Bypassing Authentication without Wildcards

In many cases, knowing multiple ways of achieving the same outcome is helpful. This enables us to bypass potential defense measures we encounter. For instance, in some cases, an asterisk may be blacklisted by the web application such that we cannot bypass authentication with the abovementioned method. Luckily, there is another way of bypassing authentication that does not use wildcards. If we alter the search filter so that the password check can fail and the search filter still returns a user, we can bypass authentication as well.

For instance, if we specify a username of admin)(|(& and a password of abc), the web application uses the following search filter:

(&(uid=admin)(|(&)(userPassword=abc)))

Due to our injected payload, the search filter contains an additional or clause which consists of the universal true operand (&) and the incorrect user password (userPassword=abc). The password check returns false since we do not know the correct password. However, the first operand of the or clause is universally true; thus, the or clause also returns true. Thus, we only need to specify a valid username to login to the specified account, thereby successfully bypassing authentication without the use of the wildcard character: