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/...
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.