On Sat, Oct 12, 2013 at 12:34 PM, Howard Chu <hyc(a)symas.com> wrote:
> On Fri, Oct 11, 2013 at 8:33 PM, Howard Chu <hyc(a)symas.com> wrote:
>> A paper and presentation making the rounds, claiming to show how webapps
>> using LDAP are vulnerable to search filter spoofing attacks.
>> Can't imagine that work like this gets peer-reviewed, because it's
>> garbage. They concoct a scenario in section 4.1.1 of their paper,
>> showing how filter manipulation can allow a webapp user to bypass
>> 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
>> 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
>> 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
>> This is also why the old pam_ldap authorization scheme was such a bad
>> 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.)
>> is why we have nssov today.
>> Of course, this is no excuse to be sloppy when writing your web apps. But
>> 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
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
> 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
> 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/