LDAP Injection

Definition

First off, let's start from the very beginning. Lightweight Directory Access Protocol or abbreviated (LDAP) is a protocol from the OSI model that appends to the Application Layer (#7). As of its abbreviation, LDAP is pretty much responsible for the allocation of resources in directories over a network. Crafting LDAP queries so as to have the effect of injections can grant you access over a lot of sections in a LDAP based page. Injection can be carried out mainly in input fields and URL parameters where the code fails to sanitize and filter the user supplied input.

How It Works

Let's take a basic example of a LDAP authentication system. The code below makes a connection to our LDAP server (in our case we use a direct URL instead of a hostname because OpenLDAP enables me to do so and because of the possibility of escaping port usage) and upon a successful match between the credentials supplied (username & password) we get logged in.

We generate a bind out of the connection query and user credentials. If the bind generated above is not successful the code will end up with an anonymous bind which would be true for the server and we get logged in. It pretty much has the same functionality as a normal php-based procedurelly written code but with a few more possibilities. As I mentioned this is a plain example of a login system based on LDAP so as to get you familiarized with the process as a whole.

Exploitation

Suppose we have a little bit of a more modified query.

search("(&(cn=Keeper)(Passwd=Hackthis.co.uk))")

The "cn" acts the role of our username and "Passwd" - you guess. What we aim to do is to login without either an actually valid username or a valid password. Considering the above code has no user data filtration we can do the following in order to get logged in:

As from the image above, we need to check the name of the input field. It's name is the value for the$_GET function. So if not properly sanitized we could log in with the following query as a username:

usrname)(&))(

Which will always be a true statement for the server because $_GET is actually equal to usrname. And as for the password - he can leave it empty or better yet type a random string just in case there is a check for empty fields.

That way the second filter (password field) will be ignored because when validating the query, the server will notice that we've supplied a true statement and won't continue to check whether the password is corresponding to the username or not.

Escalating Privileges

Suppose, we've got a page, after successfully logging in, with files that are only accessible by users of a predefined rank (the picture shows the result of the injection).

Let's take a look at our code that monitors and displays the content depending on the user's rank.

(&(page_location=crypts)(rank=registered))

Our goal is to alter our rank. So we need to supply at least one true statement so as to get access to the directory. First we finish the query (colored green) and then we start it again (colored red) so as to fit the whole request.

page_location=crypts)(rank=*))(&(page_location=crypts

In this case we get the following result from the query that has been executed:

(&(page_location=crypts)(rank=*))(&(page_location=crypt)(rank=registered)

Hope you got something out of it. Thanks for reading!