Partially controlling LDAP BindDN parameter

Question

In an application I was assessing, I found an interesting piece of code that took my attacker-supplied input and put it into the bindDN while preparing to connect to an LDAP server.

[USERNAME]@domain.com

Specifically, I can inject whatever I want into the [USERNAME] in the above sample bindDN, including something like testusername@anotherdomain.com@domain.com. I do not control the LDAP URL though. Is there anything risky security-wise with this small bug?

Have you read https://www.owasp.org/index.php/Testing_for_LDAP_Injection_(OTG-INPVAL-006)? Without knowing what the LDAP is used for, there could also be flaws in the business logic. — multithr3at3d, Jan 11 '20 at 15:55

score 2 · Accepted Answer · edited Oct 07 '21 at 08:14

The following points are worth considering in any attempt to leverage this, though I don't believe anything except attempts at denial of service would work.

Where LDAP URLs are used, these do not support in-band credentials in the URL, as the (now deprecated) method that HTTP URLs used "http://user:password@host/". There should be no way to inject a malformed bind username into such URLs (typically used for search queries) to alter their effect. However, some directory implementations support non-DN usernames in a bind operation — specifically Active Directory (userPrincipalName); or OpenLDAP with SASL and/or olcAuthIdRewrite/ olcAuthzRegexp. If OpenLDAP is configured to take a non-DN bind username (in the form of an email address or uid @realm), or otherwise uses the rwm overlay to rewrite in bindDN context, and formulates an LDAP search URL to determine the real user DN, this will only be as robust as the administrator's rewrite instructions, and could be subject to injection of malformed usernames. This is fairly unlikely, and probably very difficult to do blind (without being able to inspect the rules). I suspect it's simply an AD backend here though.

On the wire, the bind request will be a DER encoded structure of the form

 0   53: SEQUENCE {
 2    1: . INTEGER 1
 5   48: . [APPLICATION 0] {
 7    1: . . INTEGER 3
10   33: . . OCTET STRING    
       : . . . 63 6E 3D .. ..            cn=user,ou=... 
45    8: . . [0] 'password'
       : . . }
       : . }

An anonymous bind will already have been created, establishing the connection. Unless there is some horrible bug in the underlying ASN.1/LDAP library (e.g. to let you formulate a username with a DER parseable trailing password of your choosing, for brute force) then the best you can probably do is exercise the parsing, escaping, or UTF-8 encoding layers, or determine the maximum size of a DN (not defined by LDAP schema).

The best you might be able to achieve is:

denial of service, possibly through the use of very long or dubiously escaped/quoted usernames
lockout of an arbitrary user - assuming the directory implements this, e.g. AD policies, and the directory service is not otherwise accessible (in which case it's probably trivial to achieve in other ways)
attempt to enumerate other users in the same domain/directory, how practical this will be depends on feedback during the authentication attempts (see this for LDAP error codes)
attempt to find another user with the same password as this user (though how that might be useful, I don't know)

Partially controlling LDAP BindDN parameter

1 Answers1