Query and command injections are some of the most devastating classes of vulnerabilities in existence. This series of blog posts will teach you how to identify and prevent this vulnerability from occurring.
What is LDAP Injection?
LDAP injection occurs when an application fails to neutralize characters that have special meaning in LDAP. Closely, resembling SQL injection, LDAP injection occurs when LDAP statements are constructed with unverified user-supplied data. This can result in the execution of arbitrary commands such as granting permissions to unauthorized queries as well as content alterations within the LDAP tree. The same advanced exploitation techniques leveraged in SQL Injection can be similarly applied in LDAP injection.
For the purpose of illustration, let’s examine a public LDAP injection vulnerability (CVE-2012-3981) that was recently identified in the popular software management tool, Bugzilla. Bugzilla, like many software products, supports integration with external authentication mechanisms such as LDAP. Up until November 1, 2012, a vulnerability existed in Bugzilla that allowed an attacker to inject arbitrary data into an LDAP directory via a crafted login attempt. Specifically, when a user submits his credentials, no validation check is performed and the username is passed as is to create the filter which will be passed to $self->ldap->search().
Vulnerable Perl code
use Bugzilla::Util;use Net::LDAP;sub _bz_search_params {my ($username) = @_;return (base => Bugzilla->params->{"LDAPBaseDN"},scope => "sub",filter => '(&(' . Bugzilla->params->{"LDAPuidattribute"}
Preventing LDAP Injection
In this example, the authors of Bugzilla leverage a third party Perl module, Net::LDAP::Util, to escape dangerous user-input supplied by the username parameter. Specifically, escape_filter_value() escapes the passed in according to RFC 4515 so that it can be safely used in LDAP filters. Any control characters with an ACII code < 32 as well as the characters with special meaning in LDAP filters ”*”, ”(”, ”)”, and ”” the backslash are converted into the representation of a backslash followed by two hex digits representing the hexadecimal value of the character.
Example Perl
use Bugzilla::Util;use Net::LDAP;+ use Net::LDAP::Util qw(escape_filter_value)sub _bz_search_params {my ($username) = @_;+ $username = escape_filter_value($username);return (base => Bugzilla->params->{"LDAPBaseDN"},scope => "sub",filter => '(&(' . Bugzilla->params->{"LDAPuidattribute"}
In general, mitigation for all injection vulnerabilities starts with input validation. As with the other prevention techniques a positive validation scheme, or white-list, is always preferred over a black-list approach. This is particularly true if you are attempting to roll your on data validation routines. The prevention sections should be sounding like a broken record by now.
