The most common LDAP Injections and how they work

In the first part of the LDAP Injections blog, we talked about the basics. The definition of LDAP Services, how they get exploited, and what environments are the most vulnerable to LDAP Injection attacks. In this post  we will go over the most common LDAP Injections and show examples so you can learn how hackers use these techniques to exploit vulnerable environments.

What are the most used LDAP Services? ADAM and OpenLDAP. Both are susceptible to injection attacks. Let’s show some LDAP Injection examples that can occur in some of these vulnerable environments:

-(attribute=value) 

IA filter can be used to make a query that’s missing a logic operator (OR and AND). An injection like:

“value)(injected_filter” 

Results in two filters (the second gets ignored while the first one gets executed in OpenLDAP implementations):

(attribute=value)(injected_filter)

ADAM LDAP doesn’t allow queries with two filters. This renders this injection useless. Then we have the & and | standalone symbols. Making queries with them looks something like this:

(&(attribute=value)(second_filter))

(|(attribute=value)(second_filter))

Filters that have the OR or AND  logic operators can make queries in which this injection:

“value)(injected_filter” 

Results in this filter:

(&(attribute=value)(injected_filter)) (second_filter)).

As you can see, this filter isn’t even syntactically correct. Yet, OpenLDAP will process it regardless. It will go from left to right and ignore all characters after the first filter closes. What does that entail? Certain LDAP Client components ignore the second filter. The first complete one is sent to ADAM and OpenLDAP. That’s how injections bypass security. 

In cases where applications have a framework that checks the filter, it needs to be correct. An example of a synthetically correct injection looks something like:

“value)(injected_filter))(&(1=0”

This shows two different filters where the second one gets ignored:

(&(attribute=value)(injected_filter))(&1=0) (second_filter)).

Since certain LDAP Servers ignore the second filter, some components don’t allow LDAP queries with two filters. Attackers then create special injections to obtain an LDAP query with a single filter. Now an injection like:

“value)(injected_filter”

Results in this filter:

(&(attribute=value)(injected_filter))(second_filter)).

How do attackers test an application to see if it’s vulnerable to code injections? They send a query to the server that generates an invalid input. If a server returns an error message, it means the server executed his query. Meaning code injection techniques are possible. Read more to find out about AND and OR injection environments.

AND LDAP Injection

In this case, the application constructs a query with the “&” operator. This together with one or more parameters that are introduced by the user is used to search in the LDAP directory.

(&(parameter1=value1)(parameter2=value2))

The search uses value1 and value2 as values that let the search in the LDAP directory happen. Hackers can maintain a correct filter construction while also injecting their malicious code. This is how they abuse the query to pursue their own objectives.

Access Control Bypass

All login pages have two text box fields. One for the username one for the password. The user inputs are USER(Uname) and PASSWORD(Pwd). A client supplies the user/password pair. To confirm the existence of this pair, LDAP constructs search filters and sends them to the LDAP server.

(&(USER=Uname)(PASSWORD=Pwd))

An attacker can enter a valid username (john90 for example) while also injecting the correct sequence after the name. This way they successfully bypass the password check. By knowing the username any string can be introduced as the Pwd value. Then the following query gets sent to the server:

(&(USER=john90)(&))(PASSWORD=Pwd))

The LDAP server process only the first filter. The query processes only the (&(USER=john90)(&) query. Since this query is always correct, the attacker enters the system without the proper password.

Elevation of Privileges

Some queries list all documents and they’re visible to users that have a low-security level. As an example /Information/Reports, /Information/UpcomingProjects, etc. files in the directory. The “Information”  part is the user entry for the first parameter. All these documents have a “Low” security level. The “Low” part is the value for the second parameter. This also allows the hacker to access high-security levels. In order to do that the hacker must use an injection that looks something like this:

“Information)(security_level=*))(&(directory=documents”

This injection results in this filter:

(&(directory=Information)(security_level=*))(&(directory=Information)(security_level=low))

If you’ve been paying attention you know the LDAP processes the first filter. The second filter gets ignored. The query that gets processed is (&(directory=Information)security level=*)). The (&(directory=Information)(security level=low)) is ignored completely. That’s how hackers see a list of documents that can usually only be accessed by users with all security levels. Even though the hacker doesn’t actually have privileges to see this information

OR LDAP Injection

There are cases where the application makes a normal query with the (|) operator. Together with one or more parameters that the user introduces. An example looks something like this:

(|(parameter=value1)(parameter2=value2))

As before, value1 and value2 are used for the search.

Information Disclosure

Some resource explorers let a user know exactly which resource is available in the system. For example, a website dedicated to selling clothing. The user can look for a specific shirt or pants and see if they are available for sale. In this situation OR LDAP Injections are used:

(|(type=Resource1)(type=Resource2))

Both Resource1 and Resource2 show the kinds of resources in the system. Resource1=Jeans  and Resource2=T-Shirts show all the jeans and T-Shirts that are available for purchase in the system. How do hackers exploit this? By injecting (uid=*) into Resource1=Jeans. This query then gets sent to the server:

(|(type=Jeans)(uid=*))(type=T-Shirts))

The LDAP server then shows all the jeans and user objects.

BLIND LDAP Injections

Hackers can deduce a lot of things just from a server’s response. The application itself doesn’t show any error messages. Yet, the code that’s injected into the LDAP filter will generate a valid response or an error. A true result or a false result. Attackers exploit this behavior to obtain answers to true or false questions from the server. We call these techniques Blind Attacks. Even though blind LDAP Injection attacks aren’t as fast as classic ones, they are easy to implement. Why? Because they work on binary logic. Hackers use blind LDAP Injections to obtain sensitive information from the LDAP Directory.

AND Blind LDAP Injection

Imagine an online shop that can list all Puma shirts from an LDAP directory. But the error messages are not returned. This LDAP search filter gets sent:

(&(objectClass=Shirt)(type=Puma*))

Any available Puma shirts are shown to the user as icons. If there are no Puma shirts available, the user won’t see any icons. This is where Blind LDAP Injection comes into play. “*)objectClass=*))(&(objectClass=void” is injected and now the application constructs an LDAP query that looks like:

(&(objectClass=*)(objectClass=*))(&(objectClass=void)(type=Puma*))

The server process only the (&(objectClass=*)(objectClass=*)) part of the LDAP filter. Now the shirt icon shows to the client. How so? The objectClass=* filter always returns an object. An icon showing means the response is true. Otherwise the response is false. The hackers now have the option of using blind injection techniques in many ways. An example of an injection:

(&(objectClass=*)(objectClass=users))(&(objectClass=foo)(type=Puma*))

(&(objectClass=*)(objectClass=Resources))(&(objectClass=foo)(type=Puma*))

Different objectClass values can be deduced with the help of these injections. If even a single shirt icon is shown, the objectClass value exists. Otherwise, the objectClass doesn’t exist. A hacker can obtain all sorts of information by using TRUE/FALSE questions via Blind LDAP injections.

OR Blind LDAP Injection

Injection in an OR environment looks like this:

(|(objectClass=void)(objectClass=void))(&(objectClass=void)(type=Puma*))

This LDAP query doesn’t obtain any objects from the LDAP directory service. The shirt icon doesn’t get shown to the client, making it a FALSE response. If an icon is shown it is a TRUE response. In order to gather information the hacker will inject an LDAP filter like this one:

(|(objectClass=void)(objectClass=users))(&(objectClass=void)(type=Puma*))

(|(objectClass=void)(objectClass=Resources))(&(objectClass=void)(type=Puma*))

It’s the same thing as with the AND Blind Injection. Keep reading to see how you can protect yourself against LDAP vulnerabilities!

How to prevent LDAP vulnerabilities

We’ve now reached the part of the blog where we tell you how to protect yourself against LDAP Injections. Unfortunately, firewalls and intrusion detection mechanisms will not help here as all of these attacks occur in the application layer. Your best option is to use minimum exposure points and minimum privileges principles. Those are some of the ways to minimize the danger of these threats. There are other options as well. To further mitigate the dangers of code injection techniques use these mechanisms:

  • Static source code analysis
  • Defensive programming
  • Advanced input validation
  • Dynamic checks

The most effective way of preventing LDAP Injection attacks is to sanitize and check variables. As variables are the building block of LDAP filters, hackers use special characters in parameters to create malicious injections. AND “&”, OR “|”, NOT “!”, =, >=, <=, ~= are all operators that need to be filtered at the application layer to ensure they’re not used in Injection attacks. 

All values which make the LDAP filter should be checked against a list of valid values in the Application Layer before the LDAP receives the query.

In summary, Part 1 and Part 2 cover the basics of LDAP Injections, explains how they work with detailed examples, and provides some prevention guidelines to protect yourself against these attack techniques.

Get the Latest Application Security News and Content

SUBSCRIBE

Scale up efforts and set the new standard of integrating security into modern development!