On Sat, Oct 12, 2013 at 12:34 PM, Howard Chu <[email protected]> wrote: > devzero2000 wrote: >> >> On Fri, Oct 11, 2013 at 8:33 PM, Howard Chu <[email protected]> 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. >>> >>> 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/
