Injection or code injection are the most common attack types against web applications, mobile applications, desktop applications, API’s, Databases, web servers and everything around or in between that takes code as an input.
One of the most common type of injection attacks, LDAP Injection, is outlined in this article. I will explain some of the common reasons why this vulnerabilities exist and I will discuss and show examples of common attack vectors and methods used to exploit these vulnerabilities to either extract data or compromise the system entirely.
According to the OWASP Top Ten Injection attacks have been the most dangerous cause of attack against web based applications since 2007 and continue to hold the number one spot on the OWASP Top Ten for 2019.
LDAP Injection: First we will discuss what LDAP is before we look at how we can attack it. LDAP stands for Lightweight Directory Access Protocol, which basically means it a mechanism to look up directory listings in a LDAP database or server and because of its lightweight design it’s well suited and used amongst many systems. LDAP is generally used for a central repository for users on a intranet or internet based application(SSO).
A LDAP directory consists of a set of attributes based off a defined schema. Each entry into this schema/directory has a unique identifier called a DN. The example below shows an entry for John Doe a fake user in a fake organisation directory.
dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: john@example.com manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top
LDAP is an open source technology so the best place to learn about it is at LDAP website here.
Ok so what about LDAP injection and how can it affect a user, business or organisation? Taking the example above we can see that the information typically associated with LDAP is sensitive data, this is usually the data a malicious user is after. So let’s say we wanted to look up users on a LDAP system.
Enumerate Users Attack
A normal LDAP query for an application would look something like
http://www.softwaresecurity.blog/people_search.aspx?(name=Shah)(zone=public)
A malicious query on the same URL would be to change the zone attribute and instead of the public value we change it to * which is most parser engines is the command for ALL. Our new query looks like this
http://www.softwaresecurity.blog/people_search.aspx?(name=Shah)(zone=*)
The result is we can return all users for SHAH in every zone in the directory, when we should only be able to return the user SHAH in the public zone. How to protect against this? Use parameterised queries or a framework that will help you validate and sanitise your data before processing. Check out the OWASP Cheat sheet for LDAP Injection prevention here. Also for common testing payloads you can refer to this cheetsheet.
Access Control Bypass Attack
Again an LDAP query is used for validating a users credentials on a successful match the user is logged in, if the match is un-successful the login process fails and an error message is returned. Sounds standard but lets see how we can exploit a vulnerable implementation of the login functionality.
A normal query would look like
https://softwaresecurity.blog?(&(name=SHAH)(password=My5up3rSecureP@55w0rd))
A malicious query on the same URL would insert an ampersand & between the name and password attributes, because only the first two attributes are parsed this would change the statement to read if name = SHAH & nothing = nothing. Executing this query on the LDAP Directory would result in a true result and therefore pass our authentication gate. Our new query looks like this
https://softwaresecurity.blog?(&(name=SHAH)(&)(password=ANYTHING))
Although the above are trivial attack vectors the impact of these exploits can lead to a full breach or compromise of a system using LDAP as an authentication mechanism. Some advice is to improve your SSDLC methodology.
- Define a secure coding standard for developers to work from. (ASVS)
- Carry out Threat Modelling (Threat Modeller)
- Create secure user stories based on requirements you are developing & threat modelling out comes. (JIRA)
- Automate the use of SCA (Whitesource)
- Automate Static Application Code Testing(SAST)
- AutomateDynamic Application Security Testing(DAST)
- Have a single pane of glass for all security issues (VMS)
- More….
Feed the results into your bug tracking system to allow for remediation actions to be part of the backlog for the following sprints. Security doesn’t have to be a blocker to development teams, it can be an integral part of the agile processes used for todays development teams.
Software Security 