LDAP Injection

1.   Introduction

The amount of data stored in organisational databases has increased rapidly in recent years due to the rapid advancement of information technology. A high percentage of the data is sensitive, private and critical to those organisations, their clients, suppliers and partners.

Therefore, databases are usually installed behind internal firewalls, protected with intrusion detection mechanisms and accessed only by applications. To access a database, users have to connect to one of these applications and submit queries through them to the database. The threat to databases arises when these applications do not behave properly and construct these queries without sanitising user inputs first.

Over 50% of web application vulnerabilities are input validation related, which allows the exploitation of code injection techniques. These attacks have proliferated in recent years causing severe security problems in systems and applications. The SQL injection techniques are the most widely used and studied but there are other injection techniques associated with other languages or protocols such as XPath or LDAP.

Preventing the consequences of these kinds of attacks, lays in studying the different code injection possibilities and in making them public and well known for all programmers and administrators. In this paper the LDAP injection techniques are analysed in depth, because all the web applications based on LDAP trees might be vulnerable to these kinds of attacks.

The key to exploiting injection techniques with LDAP is to manipulate the filters used to search in the directory services. Using these techniques, an attacker may obtain direct access to the database underlying an LDAP tree, and thereby to important corporate information.

This can be even more critical because the security of many applications and services relies on single sign-on environments based on LDAP directories.

2. LDAP Overview

The  Lightweight  Directory Access Protocol is a protocol for querying and modifying directory services running over TCP/IP. The most widely used implementations of LDAP services are Microsoft ADAM (Active Directory Application Mode) and OpenLDAP.

LDAP directory services are software applications that store and organize information sharing certain common attributes; the information is structured based on a tree of directory entries, and the server provides powerful browsing and search capabilities, etc. LDAP is object- oriented, therefore every entry in an LDAP directory services is an instance of an object and must correspond to the rules fixed for the attributes of that object.

 Due to the hierarchical nature of LDAP directory services read-based queries are optimised to the detriment of write-based queries.

LDAP is also based on the client/server model. The most frequent operation is to search for directory entries using filters. Clients send queries to the server and the server responds with the directory entries matching these filters.

LDAP filters are defined in the RFC 4515. The structure of these filters can be summarized as: Filter = ( filtercomp )

Filtercomp = and / or / not / item

And = & filterlist Or = |filterlist Not = ! filter Filterlist = 1*filter

Item= simple / present / substring Simple = attr filtertype assertionvalue Filtertype = ”=” / ” ~ =”/ ”>=” / ”<=” Present = attr = *

Substring = attr ”=” [initial] * [final] Initial = assertionvalue

Final = assertionvalue

All filters must be in brackets, only a reduced set of logical (AND, OR and NOT) and relational (=,>=,<=,~=) operators are available to construct them. The special character “*” can be used to replace one or more characters in the construction of the filters.

Apart from being logic operators, RFC 4256 allows the use of the following standalone symbols as two special constants:

-    (&)      -> Absolute TRUE

-    (|)        -> Absolute FALSE

3. Common LDAP environments

LDAP services are a key component for the daily operation in many companies and institutions. Directory Services such as Microsoft Active Directory, Novell E-Directory and Red Hat Directory Services are based on the LDAP protocol. But there are other applications and services taking advantage of the LDAP services.

These applications and services used to require different directories (with separate authentication) to work. For example, a directory was required for the domain, a separate directory for mailboxes and distribution lists, and more directories for remote access, databases or web applications. New directories based on LDAP services are multi-purpose, working as centralised information repositories for user authentication and enabling single sign-on environments.

This new scenario increases the productivity by reducing the administration complexity and by improving security and fault tolerance. In almost every environment, the applications based on LDAP services use the directory for one of the following purposes:

–  Access control (user/password pair verification, user certificates management).

–  Privilege management.

–  Resource management.

 Due to the importance of the LDAP services for the corporate networks, the LDAP servers are usually placed in the back end with the rest of the database servers.

4. LDAP Injection in Web Applications

LDAP injection attacks are based on similar techniques to SQL injection attacks. Therefore, the underlying concept is to take advantage of the parameters introduced by the user to generate the LDAP query. A secure Web application should sanitise the parameters introduced by the user before constructing and sending the query to the server. In a vulnerable environment these parameters are not properly filtered and the attacker can inject malicious code .

1.JPG

6. Blind LDAP Injection

Suppose that an attacker can infer from the server responses, although the application does not show error messages, the code injected in the LDAP filter generates a valid response (true result) or an error (false result). The attacker could use this behavior to ask the server true or false questions. These types of attacks are named “Blind Attacks”. Blind LDAP Injection attacks are slower than classic ones but they can be easily implemented, since they are based on binary logic, and they let the attacker extract information from the LDAP Directory.

6.1.  AND Blind LDAP Injection

Suppose a web application wants to list all available Epson printers from an LDP directory where error messages are not returned. The application sends the following LDAP search filter:

  (& (objectClass=printer)(type=Epson*))

 With this query, if there are any Epson printers available, icons are shown to the client, otherwise no icon is shown. If the attacker performs a Blind LDAP injection attack injecting “*)(objectClass=*))(& (objectClass=void“, the web application will construct the following LDAP query:

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

Only the first complete LDAP filter will process:

(&(objectClass=*)(objectClass=*))

 As a result, the printer icon must be shown to the client, because this query always obtains results: the filter objectClass=* always returns an object. When an icon is shown the response is true, otherwise the response is false.

From this point, it is easy to use blind injection techniques. For example, the following injections can be constructed:

(&(objectClass=*)(objectClass=users))(&(objectClass=foo)(type=Epson*)) (&(objectClass=*)(objectClass=resources))(&(objectClass=foo)(type=Epson*))

This set of code injections allows the attacker to infer the different objectClass values possible in the LDAP directory service. When the response web page contains at least one printer icon, the objectClass value exists (TRUE), on the other hand the objectClass value does not exist or there is no access to it, and so no icon, the objectclass value does not exist(FALSE).

Blind LDAP injection techniques allow the attacker access to all information using TRUE/FALSE questions.

7. Securing Applications against Blind LDAP Injection and LDAP Injection attacks

The attacks presented in the previous sections are performed on the application layer, therefore firewalls and intrusion detection mechanisms on the network layer have no effect on preventing any of these LDAP injections. However, general security recommendations for LDAP directory services can mitigate these vulnerabilities or minimise their impact by applying minimum exposure point and minimum privileges principles.

Mechanisms used to prevent code injection techniques include defensive programming, sophisticated input validation, dynamic checks and static source code analysis. The work on mitigating LDAP injections must involve similar techniques.

It has been demonstrated in the previous sections that LDAP injection attacks are performed by including special characters in the parameters sent from the client to the server. It is clear therefore that it is very important to check and sanitise the variables used to construct the LDAP filters before sending the queries to the server.

In conclusion, we see that parentheses, asterisks, logical (AND “&”, OR “|” and NOT “!”) and relational (=,>=,<=,~=) operators must be filtered at the application layer.

Whenever possible, values used to construct the LDAP search filter must be checked against a list of valid values in the Application Layer before sending the query to the LDAP server.