Many applications use the Lightweight Directory Access Protocol (LDAP) for managing credentials and authenticating users. If an application does not carefully handle user input before adding it to LDAP queries, a malicious user can modify query logic to authenticate herself without knowing any credentials, get access to sensitive information, and even add or delete content.
To test for LDAP injection, enter the following in input fields suspected to be used in LDAP queries and watch for unusual responses from the server. An unusual response may be a random user record, a list of all users, and so on. If such an unusual response is received, then the application is vulnerable to LDAP injection.
To attempt LDAP injection during user authentication, attempt to enter the strings as the username and/or password where normalInput should be replaced with something legitimate (a valid username/password). Also, attempt entering a real username in the system along with one of the strings as the password, and attempt entering a real password in the system along with one of the strings as the username.
With LDAP injection, an attacker's goal involves either authenticating without credentials or getting access to sensitive information. This involves guessing what the underlying LDAP query looks like and then injecting specially crafted input to change its logic.
Example 1. Sample LDAP query for searching by username and password
(&(cn=userName)(password=userPassword))If the application executes the above query and assumes that the user is authenticated if the query returns at least one record, then the attacker could authenticate without a username or password if he enters * as the username and the password.
Note that an attacker can leverage LDAP injection in many different ways. For example, consider what could happen when the application executes the query shown in Example 2 and then checks the password in the returned record to authenticate a user.
Example 2. Sample LDAP query for searching by username only
(&(cn=userName)(type=Users))The application may contain account lockout functionality such that after three consecutive invalid login attempts, it locks out the user account as a security measure. Consider what happens when the attacker enters userName)(password=guess as the username and guess as the password. The LDAP query becomes (&(cn=userName)(password=guess)(type=Users)) and will return a record if and only if the password for user userName is guess. As far as the application is concerned, if no record is returned, the username entered by the attacker is invalid, and so, there is no account to lock out. Once the attacker guesses the correct password, she is authenticated successfully. Thus, the attacker effectively subverts the account lockout mechanism and can brute-force passwords.
This book's authors have seen a real application susceptible to LDAP injection where an attacker could enter * as the username and any valid password in the system to successfully authenticate in the application. Entering * as the username would return all records in the LDAP store, and the application detecting that multiple records were returned would check the password entered by the attacker against every single one of the returned records and would authenticate the user if a match occurred in any record! The security of the application was thus reduced to the attacker's ability to guess the weakest password in the system.
In general, when testing for LDAP injection interactively, it is helpful to monitor the actual queries being generated by the application to tune the attack to the particular application. There are several ways in which this can be done. If SSL is not being used to protect communication between the application and the LDAP server, a network sniffer can be used to view the application's queries as well as the LDAP server's responses. The application's logs or LDAP server logs are also places where the generated queries might be available.