Analysis: Detecting LDAP injections

It all started to go wrong when web applications started to replace internal desktop applications.

One manager in one of the many companies around the globe proposed: "We should authenticate access to this application using our Active Directory!" and after some minutes, a developer wrote a piece of code that looked like:

The idea of having a centralised location for authenticating users is actually very good; but as usual the problem lies within the implementation.

For LDAP injections - which are very similar in nature to SQL injections - the issue is that the developer is creating an LDAP query by concatenating user controlled variables like "username" and "pwd" with fixed strings like "(&(user=".

This results in the user being able to partially control the LDAP query that's being executed on the backend server, thus controlling the result, and finally (in some cases) the application's execution flow.

Let's see what happens when a regular user logs in to the web application:

• User browses to http://web-app/login.aspx
• User enters his credentials, username:andres / password:foobar
• The web application concatenates the input variables with the fixed strings and sends (&(user=andres)(password=foobar)) to the LDAP server
• LDAP server will return the expected info and execution continues as the developer intended
  

But intruders may try the following:

• Intruder browses to http://web-app/login.aspx
• Intruder wants to impersonate "andres", so they enters the following information, username:andres)(&) / password: notimportant
• The web application concatenates the input variables with the fixed strings and sends (&(user=andres)(&))(password=notimportant))
• The LDAP server is now going to execute a completely different query, which will allow the intruder to bypass the login and impersonate the user

A couple of important notes to keep in mind are that this type of vulnerability can affect any web application, disregarding which language it was written in and which LDAP backend it uses.

The following is an example of what's shown in the Rapid7 NeXpose web user interface when an LDAP injection is found, including the vulnerable script and parameter: