Coders Conquer Security: Share & Learn Series - LDAP Injections17th January 2019
The vast majority of computer systems use Lightweight Directory Access Protocol (LDAP). It’s used to maintain distributed directory information services over any Internet Protocol (IP) network. So basically, it functions as a way to keep track of users.
LDAP is often used as an authentication source by apps to see if a user has permission to perform various actions, especially as it pertains to their defined role within an organization. For example, only those in accounting might be able to use company accounting software. Applications will often be programmed to check an LDAP table to ensure that users are acting within their established permissions.
Problems can occur when malicious users can manipulate an LDAP query. Doing this can trick the receiving server into executing invalid queries that would normally not be allowed, or even granting high level or administrator access to invalid or low-security users without a password.
LDAP injections can be tricky, but in this episode, we will learn:
- How they work
- Why they are so dangerous
- How you can put defenses in place to stop them.
How do Attackers Use LDAP Injection?
One of the reasons that LDAP-based attacks have remained popular for years is the fact that almost every computer system uses it. LDAP is open-source and works extremely well, so not a lot of alternatives have been created.
At its core, LDAP is a database that tracks valid users within an IP-based computer system or network. It can allow users to share information about systems, networks, servers, applications and even other users on the same network.
Information is stored by LDAP in the equivalent of a database line or record that is called a distinguished name, which is often abbreviated as DN. Each DN is unique. As an example, this is what a DN might look like for a user who works in the Chicago accounting office of a large corporation.
cn=James Smith, ou=Corporate Accounts, dc=Chicago, do=Parkview
To ensure that each DN is unique, various codes can be added to the record, such as “+”, “/”, “=” and a few others. Spaces before or after a record can also be inserted to ensure that even if there are two James Smiths working in Corporate Accounts in the Chicago Parkview Office, they will each have individual DNs.
Applications generally use LDAP to allow users to send queries about specific DNs, such as, for example, when trying to locate the correct contact in the payroll department to talk about a mistake on their check. LDAP injections can happen when there is no validation of the user-provided parameters in search queries. In that case, hackers can manipulate benign searches to bypass authentication mechanisms or execute additional arbitrary queries. This can trick the server into displaying results that should not be allowed, such as user passwords, or even cause an application to grant access to high-security areas within the network, with or without a valid password.
Why are LDAP Injections so Dangerous?
The biggest danger with LDAP injections is likely the proliferation of the protocol throughout the majority of IP computer networks worldwide. It makes for an easy stepping stone for hackers looking to steal information, or to elevate their privileges on a network. No trained hacker will fail to check if LDAP injections are possible, so security teams must ensure that those holes are always closed.
Specifically, quite a few applications are programmed to help valid users find limited information about users and groups within an organization, or any other information contained in the DNs. For example, an app might allow someone to use LDAP to search for the contact information of corporate accountants working in Chicago, which would return our friend James Smith from the above example. Depending on permissions, this is likely a perfectly valid use of an LDAP query.
The danger comes when a malicious user can add parameters unfiltered the query, changing the nature of the search and tricking the server into providing information that should not normally be given. For example, by adding a user=* string, attackers could get information about every single user at an entire organization, something that should probably never be allowed.
For applications that use LDAP for authentication, the problem can be even worse. Attackers can use, for example, the (&) string at the end of an LDAP query to trick the server into thinking the argument is true. If an app uses LDAP to validate a password, forcing a True argument through an LDAP injection might allow an unauthorized user to log into the network as an administrator, even without a password.
Making LDAP Injection an L-DON’T in your Network
One of the best ways to prevent LDAP injections is to implement something like LINQtoAD or other frameworks designed specifically to resist it. This may not be possible if a network already has applications that are leveraging LDAP queries. However, even in that case, it’s still a good idea for every new application to use injection-resistant frameworks moving forward.
Existing applications that use LDAP can also be hardened against injections through the use of whitelist validation and input sanitization. Where possible, restrict user input to a limited set of trusted values. Otherwise, user input that is part of an LDAP query should be sanitized first, and don’t forget to include GET and POST parameters, cookies and HTTP headers as they can also act as attack vectors. Do not write your own functions to perform input sanitization; use a trusted third-party security focussed library or built-in framework APIs instead.
Beyond targeted fixes, good computing practices like assigning LDAP querying applications the least privilege needed on a network can also help. That way, if the worst should happen and an LDAP injection gets through, the damage would be mitigated.
More Information about LDAP Injections
For further reading, you can take a look at the OWASP writeup on LDAP Injections, or the injection prevention cheat sheet. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues’ gallery of other threats, visit the Secure Code Warrior blog.