[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: "LDAP Injection" attacks

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