LDAP is a widely-known protocol, and there is a good number of websites that use LDAP services. If you are using Microsoft's AD or Red Hat Directory services, LDAP is in their core.
Serving as a repo/directory of authentication data and enabler of the SSO environment, the service is very helpful when it comes to managing who can access a resource, who has the privilege to modify a resource, and so on.
But imagine if this data got leaked? Big trouble, isn’t it? Your digital assets will be at risk.
Well, LDAP injection could lead to the same. If, as a developer or website owner, you are unaware of what it is, how it can affect your site/application, or how you can prevent/counter it, you will be in bigger trouble. So, be fully aware by reading ahead.
In case you have heard of SQL injections and have knowledge of LDAP’s working, you already have a rough idea about it. But, as we are here to give you an accurate idea, let’s explain it straightforwardly.
In an LDAP Injection attack, a threat actor plays with the query input to get unauthorized access into the storage directory. As this directory may contain your organization’s or end-users’ e-mails, usernames, and passwords, such intrusion could have fatal results.
In general, the attackers look for security loopholes in a digital solution using LDAP services. Taking advantage of the inefficient filtering mechanism, he sends unsanitized user input data (e.g. LDAP queries to crack into the system) and tries to enter the application.
Upon succeeding, he may change, delete, misuse, or add access data, depending upon what is his intention.
Let us share with you an LDAP injection example to explain it better:
A typical LDAP query is a combination of various characters, symbols, quotes, etc. It may have multiple ampersands and asterisks. Now, if an attacker reaches an LDAP-powered login page and knows a username, he may manipulate the system in the password field by entering a LDAP query that makes the authenticator ignore this field.
Result will be that this attacker will enter the account owned by the user, whose username was entered. No password needed.
Similarly, a higher level of attack could help the threat-actor enter the LDAP directory and even modify the LDAP tree. In this scenario, this attacker can end the privileges or organizational user, give privileges to whoever he wants, and disturb the whole asset/data rights hierarchy of a website/organization.
Some websites, for example e-Commerce stores or information-driven websites, let their users search products or filter content/information by categories. If the attacker could get a common parameter for this information/resource set, he can pass the parameter’s value as ‘*’ (asterisk), which means ‘all’, and get access to the whole pool of information.
In this type of attack, the attacker does not get access to the root directory, but a particular user’s account and data. To do so, he may fool the system due to its weak filtering arrangements. A metacharacter (e.g., a symbol or an ampersand) is generally used to skip validation and bypass the identity-verification.
For example, an intruder will skip to enter the username or password, but an LDAP query allows him to escalate without authorization.
Your organization may have a lot of data that is available to everyone who is part of your organization, or has an account. This type of data includes general notices, information, reports, project details, and so on.
Here, you are only filtering your data by user roles or security levels, while keeping everything in the same directories. So, through privilege escalation, if the attacker could succeed at making the authenticator process ignore the user role, privilege level, or security level, he will have the ability to view everything present in the directory.
This one is very similar to SQL injections, as it works where binary logic is applicable. For example, if the server needs the answer 'TRUE' (1) or 'FALSE' (0) to trigger an action, the attacker just needs to provide his preferred binary input to gain unauthorized access. Though it may seem easy, executing such an attack is more time-consuming and full of trial-and-errors.
LDAP queries allow the use of conditional operators, and this is where an attacker gets the chance to temper them. A typical conditional query may have multiple opening and closing quotes, alongside AND and OR operations. If one could insert parameters and parentheses in a way that still makes a valid query, bypassing the security/authentication is possible.
An LDAP query constructed using various ‘&’ operators is AND type. Here, if all the values are matched, the logic will succeed. So, the attacker will have to ensure maintaining the injected code in a way that it does not turn the result into FALSE (0).
For example, to fetch details about the Titan’s female-only watches, the attacker can modify the actual query like this:
Example:
In this type, just one condition among the given ones should be true, and the data is processed left to right. So, if the attacker could insert extra conditions (malicious code) in a query with its output as TRUE, he can gain the access to the data he prefers.
Example:
If an AND query doesn’t send any output, it means that the server is vulnerable to blind intrusions. So, the attacker will look for the objects that return no input and fetch values of wider data sets through them.
Example:
Say, an online bakery shop returns no output when this search for ‘cake’ of type ‘chocolate’ is executed:
Now, it’s because there is no chocolate cake available for sale at present. But if the attacker searches for ‘*)(objectClass=*))(&(objectClass=void’. The query string will be:
So, the output will contain all chocolate items, e.g. cookies, candies, etc.
The blind LDAP injection of ‘OR’ type works on the same lines as ‘AND’, but it is applied on queries that are formed using ‘OR’ conditions.
Example:
If the attacker had to crack a OR type LDAP in previous example, the query to use is:
Though attackers need to add/insert malicious code in both cases, bypassing SQL and LDAP through injection cannot be considered the same. The main difference is just of the language used for queries and the variety of apps/systems they affect.
SQL injection exploits the web form that validates data using an SQL database. On the contrary, information in LDAP directories is the target of an LDAP injection. So, the latter is more about organizational data and users.
Severity of these intrustions must be clear to you by now. So, as a website owner or creator, you must be willing to know about how to prevent them or stop them from causing big damages. Well, here is how:
Sanitized input reduces the chances of injection. For instance, if you add validations for asterisks, AND, OR, quotes, and other such symbols that can alter your coded queries, users won’t be able to bypass the mechanism.
You may also do allow-listing to make things even secure for your application. This process lets you specify a particular range of symbols (e.g., digits from 0 to 9, characters from A to Z, and so on) that will be accepted as a part of input.
It is better to avoid using ‘(‘ or ‘)’ in the LDAP queries during their constructions. It will prevent attackers from adding one or multiple opening/closing brackets in a query and changing its meaning.
Checking the static code, verifying the quality of all modules in your application, and testing the created application (manually and using tools) will help you find vulnerabilities in your app before the threat-actors could exploit them.
It is suggested that you follow the zero or least privilege method while allocating various users or hierarchies their roles in your networks. It will help you control the user access to LDAP server more efficiently. For the times when an app has to process a request on behalf of another user/app, implementing proxies and authentication is a good idea.
Mostly (or every single time), attackers run various queries and send multiple requests before they actually succeed in an LDAP injection. Having a mechanism to identify such alien behavior is not tough, provided you have enabled controls or checks for the same.
Here are the best practices to detect attackers' attempts and prevent the insertion from happening before your business bears the issues caused by it:
Application and API security cannot be ignored, right? After all, your LDAP directory’s data will be fetched through these. You must find ways to do optimal security testing and consult security specialists if your app is secure enough. For API security, you can try this platform and do full-fledged testing efficiently.
For the LDAP-powered applications, it is essential to take care that intruders do not leverage from their carelessness or vulnerabilities. To achieve so, you must utilize all methods that prevent LDAP injection and other possible cyberattacks. Hope the above article will help you attain the right level of security.
Subscribe for the latest news