LDAP injection attack and prevention
LDAP is a way for organisations to store user credentials and use them later. It provides access control as well as mechanisms to read and modify data. If the LDAP server isn’t properly configured or secured with another layer of protection, then it could be vulnerable to an attack called LDAP injection.
However, you can only protect your applications if you: 1) know what LDAP is and 2) understand what can go wrong with it. You don’t necessarily need to be an expert in LDAP, but basic knowledge helps a lot.
It does not provide any security mechanisms, such as encryption or authentication services, but relies on other protocols (such as SSL/TLS) for these functions. Injection attacks are among the most difficult security issues to prevent because they occur at the boundary between untrusted inputs and trusted output. This article will explain what this is and how you can protect your system from it.
What is LDAP?
The acronym LDAP stands for “Lightweight Directory Access Protocol”. In a nutshell, it’s a protocol that allows clients to query and update the contents of a directory server.
LDAP (lightweight directory access protocol) is a network protocol that allows information to be distributed across a global network of servers using TCP / IP. All servers work to create common directory services within a network. LDAP supports various encryption/hash formats to store passwords such as crypt, MD5, clear, sha.
You can think of it as your ID card, but not physical; rather in electronic form that tells other people who you are when they need to know. LDAP helps authenticate users by storing their usernames and passwords and providing access whenever necessary.
What is the importance of LDAP servers?
LDAP’s primary functionality is to serve as a central hub for authentication. LDAP helps organizations store user credentials (usernames and passwords) and then access them later, like when the user attempts to access an LDAP-enabled application. The stored credentials in your organization will authenticate you if they are accessed by the right person at that time -usually yourself!
LDAP servers are an important element of network infrastructure. The directory information can be used for many purposes, but today there is an emphasis on using them to store user profiles that are being accessed by several applications.
Applications will typically use LDAP server-side controls to validate a user’s identity. It’s common to see LDAP requests in applications when validating or logging in users. Some examples would be: ldap_search(), ldap_bind() ldap_get_entries(), ldap_search…etc
What is LDAP injection?
LDAP injection is a form of attack that exploits the way certain servers handle requests. It is an attack vector used to exploit web applications that prepare LDAP statements based on user input.
This attack situation arises when an application fails to sanitise user input, it is possible to modify LDAP statements leading to query execution based on the attacker’s choice of input.
It can be dangerous for your company’s security, and while it may not happen often, you should be aware of how to prevent it from happening at all. We’ll walk you through what LDAP injection is as well as the steps you can take to reduce your vulnerability.
What are some symptoms of an LDAP (Lightweight Directory Access Protocol) injection attack?
Similar to SQL injection and other code injection attacks, this situation occurs when unsanitised user input is inserted by the application into an LDAP statement. It is a web application attack to leverage LDAP.
Depending on the severity of the attack, there may not be any noticeable symptoms present in most cases such as when no data was compromised or taken. However, the two most popular approaches observed by the pen testing community are:
- Authentication bypasses leading to accounts getting hijacked (logon, password reset), the elevation of privileges or modifying objects within the LDAP tree
- Information disclosure leading to the disclosure of all assets objects that a user isn’t intended to view or evading restrictions
How does LDAP injection work?
The goal of an LDAP injection attack is to take advantage of a server that doesn’t properly validate input from a user before processing the request. This lets attackers alter LDAP application requests in order to send information they shouldn’t be able to access or run unauthorised functions to carry out malicious activities.
Active Directory application mode (ADAM) LDAP does not allow two filters in a query. Therefore, when processing LDAP queries, OpenLDAP will process from the start and stop after the first search filter closes. This means some LDAP clients ignore the second search filter and only the first is sent to Active Directory LDAP (or OpenLDAP). This technique is how attackers bypass LDAP security.
Usually, the LDAP server is queried in the form of requests with filters and operators that are requests for LDAP directory entries. Upon a successful match, the server returns the requested entries from the database.
The following is an example of an entry in the LDAP Data Interchange Format (LDIF) record:
dn: cn=The Editor,dc=example,dc=com objectClass: organizationalRole cn: The Editor
Search filters are defined as per the RFC 4515 document.
A few examples of filters and operators are:
- * matches any character
- | is a logical OR operator
Therefore, when it is used in search filter requests, for example,
- (cn=*admin) will match all entries with a common name containing admin.
- (|(cn=*admin)(cn=*sql)) will match all entries with name containing admin or SQL
OR and AND logical LDAP injection examples
injection examples utilising OR and AND logical operators will base queries like this:
(|(param1=sql)(param2=passwords)) (&(param1=sql)(param2=passwords))
Login bypass examples
Where wildcard (*) is used, an injection query would look like this:
param1=* param2=*
will change to the LDAP query looking like this:
(&(param1=*)(param2=*))
Similarly, with inputs such as:
param1=*)(& param2=*)(&
The above inputs when submitted to the backend shall form this LDAP query:
(&(param1=*)(&)(param2=*)(&))
Blind LDAP Injection
Blind LDAP injection is an attack that utilizes a similar methodology as SQL Injection, but instead of targeting the database, it targets LDAP queries. Blind LDAP injection is actually easier than blind SQL injection mainly because LDAP tends to be limited to searches and basic injection techniques(replacing field values).
Attribute discovery
Attackers can query for various attributes by observing server responses. Just like a typical injection situation, if a value exists in the backend, the server returns a valid response. If a value is non-existent, it results in an error or empty response.
For example, an application uses an AND filter to answer user queries however, an attacker injects input to check if any such attributes and their values exist in the database:
(&(user=harry)(role=*))(objectClass=user))
If harry is the valid input against the user attribute and role exists, the attacker will receive a valid response. In case of a false response, an attacker would try more attributes to enumerate the valid one.
Booleanization
This process involves series of true/false tests to figure out specific attribute values based on series of requests with wildcards/operators use.
For instance, role=a* sent in the query input would obtain a valid response if a role starting with ‘a’ exists. This technique is then reused with ab*, ad*, adm* and so on to identify the correct value.
How to prevent LDAP injection attacks?
The two commons ways to prevent LDAP injection attacks are:
Enabling bind authentication
If LDAP protocol is configured with bind Authentication, attackers would not be able to perform LDAP injection attacks because of verification and authorization checks that are performed against valid credentials passed by the user.
An attacker can still bypass bind authentication through an anonymous connection or by exploiting the use of unauthenticated bind: Anonymous Bind (LDAP) and Unauthenticated Bind (LDAP).
Validating and sanitising input.
This is highly recommended as there is no silver bullet solution for LDAP injection attacks in the form of blacklisting or whitelisting certain characters. Input can only be validated prior to LDAP queries hence LDAP injections are best prevented when queries are not executed. This is similar to SQL injections in which data is validated and sanitized before being passed to the database queries.
Escape variables using the LDAP encoding
LDAP encoding is a function that converts binary characters to the equivalent ASCII character for purposes of transmission. It can be used to encode only certain characters, such as those that might be special and need XML escaping here ‘&’. This may result in an attack getting blocked because of this conversion process.
LDAP injection vulnerabilities can also be prevented by using mod_authldap which is an Apache module that protects against injection attacks. It separates the user name from the password into two different fields and then validates both separately to ensure no bad characters are passed in the connection.
Additional, but basic, defences to be adopted by applications should be:
- Implement the popular network security principle – the principle of least privilege (PoLP) to LAP binding accounts in your environment.
- Allow-list input validation to identify unnecessary input before it is passed to the LDAP query.
In general, as per standard input validation best practices, both syntactical and semantic level input validation should be applied.
The OWASP cheat sheet is a great source of web application security resources, specifically in this case LDAP cheat sheet.
Conclusion
Application security is a big concern for many businesses and it’s easy to see why. LDAP injection attacks often result in authentication bypasses, information disclosures, data corruption, denial of service (DoS), or other types of system intrusions that can have a significant impact on your business operations. Sometimes these are simple authentication and security bypasses that could lead to sensitive data leakage.
Fortunately, there are steps you can take to help prevent these sorts of disasters from happening at your company. The first thing you should do before deploying any new applications or integrations with external sources is to perform secure reviews by penetration testers who specialise in application security assessments. They will be able to identify potential vulnerabilities which may not come up during other development phases and offer advice about how best to avoid those issues altogether.
Get in touch to discuss your application security concerns or schedule a free consultation call.
