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.
Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access. This is also why the old pam_ldap authorization scheme was such a bad idea, it relied on the LDAP client (pam_ldap) to correctly implement authorization, instead of the server. (Multiply that by hundreds or thousands of clients and you have an unmanageable, insecurable mess.) This is why we have nssov today.
Of course, this is no excuse to be sloppy when writing your web apps. But if you've configured ACLs to adequately protect your data, then it doesn't matter how sloppy your clients are.
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
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.
Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access.
Ack, but ACLs only protect what's stored inside the LDAP server.
There could be possible attacks when mapping username to wrong user entry or when reading access control data from wrong LDAP entries based on user's input which protects other app data.
Ciao, Michael.
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
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.
Agreed.
Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access.
Ack, but ACLs only protect what's stored inside the LDAP server.
There could be possible attacks when mapping username to wrong user entry or when reading access control data from wrong LDAP entries based on user's input which protects other app data.
I suppose in a poorly designed app this is possible. "Reading access control data from wrong LDAP entries" is also wrong design. There is no reason for an app to ever read access control data. At most, it only needs to do an LDAP Compare operation and let the server verify such data. And again, Compare requests aren't vulnerable.
Howard Chu wrote:
I suppose in a poorly designed app this is possible.
I think what's the paper is about: There are indeed many poorly designed apps out there.
"Reading access control data from wrong LDAP entries" is also wrong design. There is no reason for an app to ever read access control data. At most, it only needs to do an LDAP Compare operation and let the server verify such data. And again, Compare requests aren't vulnerable.
In federation deployments the component controlling access to a local resource most times does not even have access to your user (LDAP) backend database.
Ciao, Michael.
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.
On Fri, Oct 11, 2013 at 8:33 PM, Howard Chu hyc@symas.com 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.
Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access. This is also why the old pam_ldap authorization scheme was such a bad idea, it relied on the LDAP client (pam_ldap) to correctly implement authorization, instead of the server. (Multiply that by hundreds or thousands of clients and you have an unmanageable, insecurable mess.) This is why we have nssov today.
Of course, this is no excuse to be sloppy when writing your web apps. But if you've configured ACLs to adequately protect your data, then it doesn't matter how sloppy your clients are.
Personally, as a penetration tester, security professional - among other things - I do not agree. O partially.
IMNSHO, the authors have simply traslated in the LDAP world the exactly same problematic that a generic web apps can have regarding SQLI. I do not think they are very different, but LDAP problem in these area are much less popular in the web apps context, probably for reasons of implementation: who like to put some structured information in an LDAP server instead of a relational db? zero or nearly so (I do, because i know LDAP but few others do the same) And I am equally convinced that when there are deficiencies in the webapp input validation the issues are actually the same. Most of the web app are based in carrying out these operations - against the relational or the ldap server - using a webapps user (not the real user), with data access privilege, in general , much broader. For ease of implementation, perhaps. And the ACL serve little in these cases, both in the case of a relational db that of a LDAP server.
Why ? the design of the application is wrong , it does not respect the principle of least privilege. A long time ago i have deployed a web application based on different levels of security privileges: the service users could access the backend LDAP server , but only if the access came from a specific ip address (an application server) and this user can could read some attribute of a specific OU of a specific DIT, others authenticated user could write some specific attribute of a subset of a DIT (and they cannot read other attribute). Using the sophisticated ACL that OPENLDAP offer, different security zone and so on.
How many would do it or do it?
Best Regards and thanks for sharing.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
devzero2000 wrote:
On Fri, Oct 11, 2013 at 8:33 PM, Howard Chu hyc@symas.com 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.
Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access. This is also why the old pam_ldap authorization scheme was such a bad idea, it relied on the LDAP client (pam_ldap) to correctly implement authorization, instead of the server. (Multiply that by hundreds or thousands of clients and you have an unmanageable, insecurable mess.) This is why we have nssov today.
Of course, this is no excuse to be sloppy when writing your web apps. But if you've configured ACLs to adequately protect your data, then it doesn't matter how sloppy your clients are.
Personally, as a penetration tester, security professional - among other things - I do not agree. O partially.
IMNSHO, the authors have simply traslated in the LDAP world the exactly same problematic that a generic web apps can have regarding SQLI. I do not think they are very different, but LDAP problem in these area are much less popular in the web apps context, probably for reasons of implementation: who like to put some structured information in an LDAP server instead of a relational db? zero or nearly so (I do, because i know LDAP but few others do the same) And I am equally convinced that when there are deficiencies in the webapp input validation the issues are actually the same.
Nonsense, the issues are nowhere near the same. SQL is a liability because with injection you can construct any statement of your choosing - Query, create, modify, or delete information. This liability exists precisely because SQL is a text-based language.
For an LDAP scenario the window of vulnerability is restricted to a search filter, only. You cannot use injection to turn an LDAP Search request into a Modify or Delete request. You cannot destroy or forge data using this "attack" - it is a much smaller attack surface, and the payoff for an attack is miniscule. This is a fact - all LDAP-based apps are inherently less vulnerable than all SQL-based apps, for this simple reason.
And again, with ACLs configured on the server, all any attacker can get is access to information they were already permitted to see, which completely closes the window of vulnerability.
Most of the web app
are based in carrying out these operations - against the relational or the ldap server - using a webapps user (not the real user), with data access privilege, in general , much broader. For ease of implementation, perhaps. And the ACL serve little in these cases, both in the case of a relational db that of a LDAP server.
Why ? the design of the application is wrong , it does not respect the principle of least privilege. A long time ago i have deployed a web application based on different levels of security privileges: the service users could access the backend LDAP server , but only if the access came from a specific ip address (an application server) and this user can could read some attribute of a specific OU of a specific DIT, others authenticated user could write some specific attribute of a subset of a DIT (and they cannot read other attribute). Using the sophisticated ACL that OPENLDAP offer, different security zone and so on.
How many would do it or do it?
Look at the volume of messages on this list related to ACLs - clearly, most OpenLDAP admins are both conscious of and conscientious about using effective ACLs.
Best Regards and thanks for sharing.
Howard Chu wrote:
Look at the volume of messages on this list related to ACLs - clearly, most OpenLDAP admins are both conscious of and conscientious about using effective ACLs.
But unfortunately the majority of web app deployments with some sort of LDAP server as backend use a *single* quite powerful system user. Deployments where the end user's authz-DN is used for access control are rather rare. It's always a very hard budget fight to change that.
To be very clear: I'm personally in favour of letting the LDAP server enforce access control as much as possible.
BTW: When designing ACLs are people here using sort of regression testing?
Also possibly manipulated search results might be used as input to other components leading to false security decisions. Really skilled attackers combine their attacks over non-obvious corner cases similar to skilled pool players playing via cushion. (Native English speakers are welcome to correct my sentence if I didn't get that right).
So papers like this are needed to remind innocent developers to properly escape user's input when constructing search filters. But the authors should not exaggerate their findings like they actually do.
Ciao, Michael.
On Sat, Oct 12, 2013 at 12:34 PM, Howard Chu hyc@symas.com wrote:
devzero2000 wrote:
On Fri, Oct 11, 2013 at 8:33 PM, Howard Chu hyc@symas.com 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.
Just in case anybody out there might be bitten by this info - client-enforced security is no security at all. This is why slapd has such an extensive ACL engine - you enforce access controls on the server, and then it doesn't matter what kind of garbage requests your clients send to you, they can only ever access information that they were allowed to access. This is also why the old pam_ldap authorization scheme was such a bad idea, it relied on the LDAP client (pam_ldap) to correctly implement authorization, instead of the server. (Multiply that by hundreds or thousands of clients and you have an unmanageable, insecurable mess.) This is why we have nssov today.
Of course, this is no excuse to be sloppy when writing your web apps. But if you've configured ACLs to adequately protect your data, then it doesn't matter how sloppy your clients are.
Personally, as a penetration tester, security professional - among other things - I do not agree. O partially.
IMNSHO, the authors have simply traslated in the LDAP world the exactly same problematic that a generic web apps can have regarding SQLI. I do not think they are very different, but LDAP problem in these area are much less popular in the web apps context, probably for reasons of implementation: who like to put some structured information in an LDAP server instead of a relational db? zero or nearly so (I do, because i know LDAP but few others do the same) And I am equally convinced that when there are deficiencies in the webapp input validation the issues are actually the same.
Nonsense, the issues are nowhere near the same. SQL is a liability because with injection you can construct any statement of your choosing - Query, create, modify, or delete information. This liability exists precisely because SQL is a text-based language
If I can buypass, for an applicaction flaw. an application that searches the validity of a username and a password, and instead It do give me all users in the OU, it is a bug or not (in the application= ?.
For an LDAP scenario the window of vulnerability is restricted to a search filter, only. You cannot use injection to turn an LDAP Search request into a Modify or Delete request. You cannot destroy or forge data using this "attack" - it is a much smaller attack surface, and the payoff for an attack is miniscule. This is a fact - all LDAP-based apps are inherently less vulnerable than all SQL-based apps, for this simple reason.
This is correct, sure.
And again, with ACLs configured on the server, all any attacker can get is access to information they were already permitted to see, which completely closes the window of vulnerability.
Most of the web app
are based in carrying out these operations - against the relational or the ldap server - using a webapps user (not the real user), with data access privilege, in general , much broader. For ease of implementation, perhaps. And the ACL serve little in these cases, both in the case of a relational db that of a LDAP server.
Why ? the design of the application is wrong , it does not respect the principle of least privilege. A long time ago i have deployed a web application based on different levels of security privileges: the service users could access the backend LDAP server , but only if the access came from a specific ip address (an application server) and this user can could read some attribute of a specific OU of a specific DIT, others authenticated user could write some specific attribute of a subset of a DIT (and they cannot read other attribute). Using the sophisticated ACL that OPENLDAP offer, different security zone and so on.
How many would do it or do it?
Look at the volume of messages on this list related to ACLs - clearly, most OpenLDAP admins are both conscious of and conscientious about using effective ACLs.
I agreed.
Best Regards and thanks for sharing.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
* Howard Chu:
Look at the volume of messages on this list related to ACLs - clearly, most OpenLDAP admins are both conscious of and conscientious about using effective ACLs.
I think the concern here is access control mechanisms fed from LDAP, not access to the LDAP database itself.
Quite a few AAA systems have configurable LDAP search filters with placeholders and construct the final filter string using simple concatenation. Manipulated filter strings could trick the system into loading (and eventually applying) the wrong set of access controls.
It might make sense for OpenLDAP to provide a version of ldap_search_ext which separates the filter and any parameters contained in it, or provide means to construct filters in a way that is more robust than string concatenation.
openldap-technical@openldap.org
-
devzero2000 -
Florian Weimer -
Howard Chu -
Michael Ströder