Injecting into LDAP
The Lightweight Directory Access Protocol (LDAP) is used for accessing directory services over a network. A directory is a hierarchically organized data store that may contain any kind of information but is commonly used to store personal data such as names, telephone numbers, email addresses, and job functions. An example of such a directory is the Active Directory used within Windows domains. You are most likely to encounter LDAP being used in corporate intranet-based web applications, such as an HR application that allows users to view and modify information about employees.
Consider a simple application function that enables users to search for employee contact details by specifying an employee name, as shown in Figure -1.
Figure -1: An LDAP-based directory search function
When a user supplies the search term GUILL , the application performs the following LDAP query:
<LDAP://ldapserver>;(givenName=GUILL);cn,telephoneNumber,department
This query contains two key elements:
■ The search filter: givenName=GUILL
■ The attributes to be returned: cn,telephoneNumber,department
In this situation, it is possible for an attacker to supply a crafted search term that interferes with one or both of these elements, to modify the information returned by the query.
Injecting Query Attributes
To retrieve other attributes in the query’s results, you must first terminate the brackets that encapsulate the search filter and then specify the additional attributes that you desire. For example, supplying
GUILL);mail,cn;
results in the query
<LDAP://ldapserver>;(givenName=GUILL);mail,cn;);cn,telephoneNumber,department
which returns an additional column containing the user’s email address, as shown in Figure -2.
Figure -2: Injecting an additional query attribute
Note the additional column containing the bogus attribute name cn;);cn . The LDAP query attributes are specified in a comma-delimited list, so everything between the first and second comma is treated as an attribute name. Note also that Active Directory will return an error if a completely arbitrary attribute name is specified; however, it tolerates invalid names that start with an actually valid name followed by a semicolon, hence the need to specify cn; after the injected string.
Going further, you can specify any number of fields to be returned in the results, and you can also specify an asterisk as the main search filter, which functions as a wildcard. For example, supplying
*);cn,l,co,st,c,mail,cn;
will return all of these fields for every user, as shown in Figure -3.
Figure -3: An attack to retrieve all information in the directory
Modifying the Search Filter
In some situations, the user-supplied input is not used directly as the entire value of the search filter but is embedded in a more complex filter. For example, if the user performing the search is only allowed to view the details of employees based in France, the application might perform the following query:
<LDAP://ldapserver>;(&(givenName=GUILL)(c=FR));cn,telephoneNumber,department,c
This uses the & operator to combine two conditions — the first controlled by the user and the second preset by the application. Supplying the search term *will return the details of all users based in France. However, supplying the string
*));cn,cn;
causes the application to make the following query:
<LDAP://ldapserver>;(&(givenName=*));cn,cn;)(c=FR));cn,telephoneNumber,department,c
which subverts the application’s original logic, removing the (c=FR) condition from the search filter, thus returning the results of all users in all countries, as shown in Figure -3.
Figure -3: A successful attack to subvert the intended search filter
Finding LDAP Injection Flaws
Supplying invalid input to an LDAP operation typically does not result in any informative error message. In general, the evidence available to you in diagnosing a vulnerability includes the results returned by a search function, and the occurrence of an error such as an HTTP 500 status code. Nevertheless, you can use the following steps to identify an LDAP injection flaw with a degree of reliability.
Preventing LDAP Injection
If it is necessary to insert user-supplied input into an LDAP query, this operation should only be performed on simple items of data that can be subjected to strict input validation. The user input should be checked against a white list of acceptable characters, which should ideally include only alphanumeric characters. Characters that may be used to interfere with the LDAP query should be blocked, including ( ) ; , * | & and = . Any input that does not match the white list should be rejected, not sanitized.
NEXT is..Exploiting Path Traversal……………………………,,,,,,,,,,,,,,,,,,,,,,,,,,,,
