the-web-application-hackers-handbook

Chapter 9 n Attacking Data Stores 353
In the preceding example, the attacker can supply the following input:
*))%00
The %00 sequence is decoded by the application server into a literal NULL byte,
so when the input is embedded into the search filter, it becomes:
(&(givenName=*))[NULL])(department=London*))
Because this filter is truncated at the NULL byte, as far as LDAP is concerned it
contains only a single wildcard condition, so the details of all employees from
departments outside the London area are also returned.
TRY IT!
http://mdsec.net/employees/13/
http://mdsec.net/employees/42/
Finding LDAP Injection Flaws
Supplying invalid input to an LDAP operation typically does not result in an
informative error message. In general, the evidence available to you in diagnosing
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.
HACK STEPS
1. Try entering just the * character as a search term. This character functions
as a wildcard in LDAP, but not in SQL. If a large number of results are
returned, this is a good indicator that you are dealing with an LDAP query.
2. Try entering a number of closing brackets:
))))))))))
This input closes any brackets enclosing your input, as well as those
that encapsulate the main search filter itself. This results in unmatched
closing brackets, thus invalidating the query syntax. If an error results, the
application may be vulnerable to LDAP injection. (Note that this input may
also break many other kinds of application logic, so this provides a strong
indicator only if you are already confident that you are dealing with an
LDAP query.)
Continued