What Is LDAP?
LDAP stands for Lightweight Direction Access Protocol. LDAP is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directory services like LDAP provide application accessible repositories for information about users, credentials, systems, and applications etc. Specifically, the protocol includes commands and syntax to search, add, remove, and modify directory entries. An application can interact with an LDAP server using a URI on the appropriate port (typically 389), or use a human readable syntax for search filters defined in RFC 2254.
It is this string format syntax that is often dynamically assembled by an application to perform a directory operation. When the LDAP search string potentially includes untrusted input, the potential for LDAP Injection exists.
What Is LDAP Injection?
LDAP Injection is a type of application vulnerability, (similar to SQL Injection) that occurs when untrusted input is integrated into an LDAP search filter, maliciously changing the meaning (i.e designer’s intent) of the statement. A Search Filter is a parenthesized expression with prefix logical operators and potentially wild-carded values. Nested expressions are used as sub-criteria. We repeat an example from the RFC to illustrate:
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
which will return records from the directory that are “Person” records AND that have EITHER a surname of Jenson (exact match) OR a common name of Babs and a last name beginning with “J” (wildcard match).
LDAP Injection Example 1
Consider an application that prompts the user for a name and that returns their contact information. To do so, the application embeds the user-supplied name into an LDAP query and then formats and displays the records returned. Let us further suppose that the application in question is a web-application, and the LDAP query criteria is passed as a query parameter such as ?sn=Smith. Perhaps the application inserts the query param directly into the string where shown below:
(&(objectClass=Employee)(sn=SN_PARAMETER_VALUE) )
Thus, when a user searches for “SMITH“, the query looks like this:
(&(objectClass=Employee)(sn=SMITH) )
On the other hand, an attacker might enter: “*)(title=Manager“, producing a query that looks like this:
(&(objectClass=Employee)(sn=*)(title=Manager) )
which returns the names of all employees that are managers. Thus, without intending to, the designer has provided attackers with a tool to perform arbitrary searches against employee records in the directory.
LDAP Injection Example 2
Another classic example exploit of LDAP Injection involves authentication. Consider an application that prompts and collects the user id and password and then submits it as a search to LDAP. The search string might resemble the following:
(&(UserId=accountId)(Password=pwd))
and the application could infer that the credentials are valid if a record is returned. However, a malicious user might provide an account id whose value is: “*)(&))“ yielding the following LDAP search string:
(&(UserId=*)(&))(Password=pwd))
Some LDAP implementations will process only the first expression and ignore the trailing text. Since (&) is always true, the expression will be true and return all records. If a non-null return implies valid credentials were presented, then and access will be granted regardless of the password provided, and we have bypassed authentication.
For insight into how to detect LDAP Injection vulnerabilities, please see the article entitled “How To Test For LDAP Injection“.
For insight into how to avoid or fix LDAP Injection vulnerabilities, please see the article entitled “How To Prevent LDAP Injection“.
For additional information, a classic treatment of the topic can be found here,
About Affinity IT Security
We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and train your developers and testers. In fact, we train developers and IT staff how to hack applications and networks.
Perhaps it was a network scan or website vulnerability test that brought you here. If so, you are likely researching how to find, fix, or avoid a particular vulnerability. We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.
Contact us to learn how to better protect your enterprise.
Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.