[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: "LDAP Injection" attacks
Michael StrÃder wrote:
Howard Chu wrote:
A paper and presentation making the rounds, claiming to show how webapps using
LDAP are vulnerable to search filter spoofing attacks.
http://www.youtube.com/watch?v=wtahzm_R8e4
http://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper/bh-eu-08-alonso-parada-WP.pdf
Can't imagine that work like this gets peer-reviewed, because it's mostly
garbage. They concoct a scenario in section 4.1.1 of their paper, supposedly
showing how filter manipulation can allow a webapp user to bypass LDAP-based
authentication. It's ridiculous drivel though, since LDAP-based authentication
uses Bind requests and not search filters. Most LDAP deployments don't even
give search/compare access to userPassword attributes in the first place.
Well, this is not really new:
https://www.owasp.org/index.php/LDAP_injection
Indeed, quite old. The blackhat paper is from 2008 and the owasp writeup is
from 2009. Not sure why they're being discussed currently, particularly since
so much of the information was flat wrong.
In the blackhat paper Section 4, page 5:
â (attribute=value): If the filter used to construct the query lacks a logic operator (OR
or AND), an injection like âvalue)(injected_filterâ will result in two filters:
(attribute=value)(injected_filter). In the OpenLDAP implementations the second filter
will be ignored, only the first one being executed. In ADAM, a query with two filters
isn Ìt allowed. Therefore, the injection is useless.
In fact libldap was changed in January 2007, over a year before this paper was
written, to reject improperly constructed filters of this form, for ITS#4648.
(git commit f1784a54e693d68fc9b9cc1b566aa0880a419d70) Aside from having the
facts completely wrong, the writing is also poor, conflating the OpenLDAP
clientside behavior with the server behavior. If in fact you could convince a
client to generate the BER for such a malformed filter, slapd would still have
rejected it because it cannot be decoded correctly on the server side (and
that has *always* been true).
I can't speak to what other LDAP client APIs might do, but regardless, the
requests described on this page would always fail if they made it to the
server, and an OpenLDAP client would have rejected the attempt in the first place.
Anyway, the paper is a bit bloated and the term "code injecting" sounds really
over-loaded here.
SQL injection attacks are generally much more powerful since an attacker can
also write data. Compared to that manipulating search requests with LDAP
filter injection is not such a massive attack vector.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/