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