hunting-ldap-injection-and-bind-trust

Hunting LDAP injection and bind trust: when a filter or a bind decides who you are

LDAP sits under a great deal of enterprise authentication and lookup, and it has two distinct injection-shaped failures. The first is classic filter and distinguished-name injection: when a request value is spliced into a search filter or a DN without escaping the directory's metacharacters, the attacker rewrites the filter's logic (turning a scoped match into a match-anything clause) or redirects the search to a different subtree. The second is a bind-trust failure: LDAP permits anonymous and unauthenticated binds, and a login flow that binds with an empty password, or treats an anonymous bind as success, authenticates an attacker who supplied no valid credential. You find these by tracing untrusted input into filter and DN construction, and by reading the bind logic for the empty-credential and anonymous cases.

When to use

• An application builds LDAP search filters or distinguished names from request input.
• Authentication is performed by binding to a directory with user-supplied credentials.
• A directory lookup uses a search base or scope influenced by untrusted input.

Scope check

Test LDAP queries and binds only against directories and applications you own or are authorized to assess, on non-production data. A confirming filter can enumerate directory entries outside the intended scope and a bind test touches authentication, so stay inside the authorized boundary. If you can't name the authorization, stop.

The loop

1. Establish the filter, DN, and bind sinks first. Inventory every LDAP search (its filter and base DN) and every authentication bind. This is the false-positive killer: a filter assembled entirely from fixed structure with properly escaped values, and a bind that rejects empty credentials, is not vulnerable. Name the search and bind sinks first.

2. Trace untrusted input into filter construction. Follow request values into the search filter. If a value is concatenated into the filter string without escaping the LDAP special characters, the attacker can inject a clause: closing the intended predicate and adding a match-anything condition, or altering the boolean logic. Confirm whether each interpolated value is escaped for the filter context.