LDAP Injection Attacks Explained

Bad Injection

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


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


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


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


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.


How to protect against credential stuffing on AWS

Credential Stuffing is an attack against a web application’s login mechanism. It is part of the Brute Force attacks outlined in the OWASP Top Ten. It is a major threat for the retail industry and gaming industry, but is not reserved to these industries alone. Credential Stuffing usually takes known username and passwords to carry out the attack, these are usually gained from data breaches, pastebin dumps, dark web e-commerce sites and more.

There are some very similar attack type’s that have the same impact as Credential Stuffing and this post will out line the application and infrastructure security mechanisms you should use to help prevent Credential Stuffing attacks. The focus of this post will be around AWS Cloud Hosting bu can apply across all over hosting platforms. It is also key to point out the separation of security approaches in order that the focus and implementation is carried out with the right people in the right layers.

Attack TypeDescription
Brute ForceTesting multiple passwords from dictionary or other source against a single account.
Credential StuffingTesting username/password pairs obtained from the breach of another site.
Password SprayingTesting a single weak password against a large number of different accounts.

Credential Stuffing attack can come from a manual user using 1 IP or can come from a group of attackers using many different IP’s and using bot’s. It is key that we are able to distinguish from an honest attempt from a user to login multiple and a malicious login attempt.

Single User IP Multiple Different Account Logins. This is usually the script kiddy or hacker n00b. These attacks are easy to detect and easy to defend and once implemented will usually deter the would be attacker off to a less secure site. Most attackers use the same automated open source free tools like Sentry MBA, Vortex and Account Hitman to carry out the attacks. All you need is a computer, internet link, malware tool and a data breach dump.

  • Elastic Load Balancer (Infrastructure Security Control)
  • AWS WAF (Infrastructure Security Control)
  • AWS CloudFront (Infrastructure Security Control)
  • AWS Shield (Infrastructure Security Control)
  • Multi Factor (Business Driven Option) (Application Security Control)
  • Capture (Application Security Control)
  • Block/BlackList IP (Application Security Control)
  • Rate Limit Header (Application Security Control)
  • Block Headless Browsers (Application Security Control)

Multiple IP’s Multiple Different Account Logins. This is not a script kiddie or n00b, take this attack seriously because the actors carrying out this attack are very serious. This multi layered attack usually comes from a group of attackers and sometimes from very sophisticated evasive techniques. To protect against this type of attack we must be prepared to go a lot deeper in our defences. The tools used to carry out these attacks are custom proxies, STORM, Black Bullet, Private Keeper, SNIPR, Sentry MBA, and WOXY, Account Hitman and more.

  • Elastic Load Balancer (Infrastructure Security Control)
  • Commercial WAF (F5) (Infrastructure Security Control)
  • AWS WAF (Infrastructure Security Control)
  • Honey Pot Redirection (Infrastructure Security Control)
  • AWS Cloud Front (Infrastructure Security Control)
  • AWS Sheild (Infrastructure Security Control)
  • AWS Route 53 (Infrastructure Security Control)
  • Capture (Application Security Control)
  • Two Step Login Process (Application Security Control)
  • Multi Factor (Business Driven Option) (Application Security Control)
  • Block/BlackList IP (Application Security Control)
  • Finger Print Client (Application Security Control)
  • Rate Limit Header (Application Security Control)
  • Rate Limit on Non residential ASN (Application Security Control)
  • Require JavaScript (Application Security Control)
  • Block Headless Browsers (Application Security Control)

In the above architecture we can see an AWS WAF service implemented. Upon detection of a known bad request the logs of this request would be filtered through various log services in order to update the WAF to block further attempts from this now known bad IP/IP Space automatically. We can see that the WAF service offers the following protection to help protect against Credential Stuffing and other related attacks:

  • Whitelist a rule to allow known good IP’s
  • Blacklist a rule to block known bad IP’s
  • SQL Injection a rule to block common patterns in the URI, query string, or body of a request containing SQL Injection.
  • XSS Injection a rule to block common patterns in the URI, query string, or body of a request containing XSS.
  • HTTP Flood detects for a large number of requests from a particular IP address, such as a web-layer DDoS attack or a brute-force login attempt
  • Scanner & Probes this component parses application access logs searching for suspicious behavior, such as an abnormal amount of errors generated by an origin. It then blocks those suspicious source IP addresses for a customer-defined period of time.
  • IP Reputation Lists this component is the IP Lists Parser AWS Lambda function which checks third-party IP reputation lists hourly for new ranges to block.
  • Bad Bot this component automatically sets up a honeypot, which is a security mechanism intended to lure and deflect an attempted attack.
When Combining AWS Shield with AWS CloudFront and AWS WAF we get a comprehensive DDoS and Brute force Protection architecture, coupled with our application security controls and we now have a much more robust, dynamic and automated way to stop the various Brute force attacks, Password Spraying, Credential Stuffing and DDoS attacks.

Route 53: You can use Amazon Route 53 to configure DNS health checks to route traffic to healthy endpoints or to independently monitor the health of your application and its endpoints. Amazon Route 53 Traffic Flow makes it easy for you to manage traffic globally through a variety of routing types, including Latency Based Routing, Geo DNS, Geoproximity, and Weighted Round Robin—all of which can be combined with DNS Failover in order to enable a variety of low-latency, fault-tolerant architectures.

AWS Shield: Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency. There are two tiers of AWS Shield – Standard and Advanced.

AWS Cloud Front: Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment. CloudFront is integrated with AWS – both physical locations that are directly connected to the AWS global infrastructure, as well as other AWS services. CloudFront works seamlessly with services including AWS Shield for DDoS mitigation, Amazon S3, Elastic Load Balancing or Amazon EC2 as origins for your applications, and Lambda@Edge to run custom code closer to customers’ users and to customize the user experience. Lastly, if you use AWS origins such as Amazon S3, Amazon EC2 or Elastic Load Balancing, you don’t pay for any data transferred between these services and CloudFront.

AWS WAF: AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF gives you control over which traffic to allow or block to your web applications by defining customisable web security rules. 

OWASP Top Ten 2019

Someone once said never commit to memory what you can write down. So here is the OWASP Top Ten for all those attending interviews and need to brush up what the current order of the OWASP Top Ten Application vulnerabilities. This is the current 2019 OWASP Top Ten.

(1) Injection 
Injection attacks happen when untrusted data is sent to a code interpreter through a form input or some other data submission to a web application. For example, an attacker could enter SQL database code into a form that expects a plaintext username. If that form input is not properly secured, this would result in that SQL code being executed. This is known as an SQL injection attack.

Injection attacks can be prevented by validating and/or sanitizing user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.

– OS
– Log

(2) Broken Authentication

Vulnerabilities in authentication (login) systems can give attackers access to user accounts and even the ability to compromise an entire system using an admin account. For example, an attacker can take a list containing thousands of known username/password combinations obtained during a data breach and use a script to try all those combinations on a login system to see if there are any that work.

Some strategies to mitigate authentication vulnerabilities are requiring 2-factor authentication (2FA) as well as limiting or delaying repeated login attempts using rate limiting.

  • Weak Password Policy
  • Weak Cryptography
  • User Access Controls

(3) Sensitive Data Exposure

If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sellor utilize it for nefarious purposes. One popular method for stealing sensitive information is using a man-in-the-middle attack.

Data exposure risk can be minimized by encrypting all sensitive data as well as disabling the caching* of any sensitive information. Additionally, web application developers should take care to ensure that they are not unnecessarily storing any sensitive data.

*Caching is the practice of temporarily storing data for re-use. For example, web browsers will often cache webpages so that if a user revisits thosepages within a fixed time span, the browser does not have to fetch the pages from the web.

– Logs
– Source Code
– Headers
– API’s

(4) XML External Entity

This is an attack against a web application that parses XML* input. This input can reference an external entity, attempting to exploit a vulnerability in the parser. An ‘external entity’ in this context refers to a storage unit, such as a hard drive. An XML parser can be duped into sending data to an unauthorized external entity, which can pass sensitive data directly to an attacker.

The best ways to prevent XEE attacks are to have web applications accept a less complex type of data, such as JSON**, or at the very least to patch XML parsers and disable the use of external entities in an XML application.

*XML or Extensible Markup Language is a markup language intended to be both human-readable and machine-readable. Due to its complexity and security vulnerabilities, it is now being phased out of use in many web applications.

**JavaScript Object Notation (JSON) is a type of simple, human-readable notation often used to transmit data over the internet. Although it was originally created for JavaScript, JSON is language-agnostic and can be interpreted by many different programming languages.

  • Extending Schema
  • WSDL

(5) Broken Access Controls

Access control refers a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example a web application could allow a user to change which account they are logged in as simply by changing part of a url, without any other verification.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls on them.

Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are, without having to constantly enter their login credentials.

  • – Allows access to restricted resources

(6) Security Misconfiguration

Security misconfiguration is the most common vulnerability on the list, and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.

(7) XSS (cross site scripting)

Cross-site scripting vulnerabilities occur when web applications allow users to add custom code into a url path or onto a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser. For example, an attacker could send an email to a victim that appears to be from a trusted bank, with a link to that bank’s website. This link could have some malicious JavaScript code tagged onto the end of the url. If the bank’s site is not properly protected against cross-site scripting, then that malicious code will be run in the victim’s web browser when they click on the link.

Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests as well as validating and/or sanitizing user-generated content. Using modern web development frameworks like ReactJS and Ruby on Rails also provides some built-in cross-site scripting protection.

(8) Insecure Deserialisation

This threat targets the many web applications which frequently serialize and deserialize data. Serialization means taking objects from the application code and converting them into a format that can be used for another purpose, such as storing the data to disk or streaming it. Deserialization is just the opposite: converting serialized data back into objects the application can use. Serialization is sort of like packing furniture away into boxes before a move, and deserialization is like unpacking the boxes and assembling the furniture after the move. An insecure deserialization attack is like having the movers tamper with the contents of the boxes before they are unpacked.

An insecure deserialization exploit is the result of deserializing data from untrusted sources, and can result in serious consequences like DDoS attacks and remote code execution attacks. While steps can be taken to try and catch attackers, such as monitoring deserialization and implementing type checks, the only sure way to protect against insecure deserialization attacks is to prohibit the deserialization of data from untrusted sources.

  • Spring < 3 is vulnerable

(9) Using Components With Known Vulnerabilities

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensuring that they are receiving components from a trusted source and ensuring they are up to date.
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

  • Shodan

(10) Insufficient Logging And Monitoring

Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

The official OWASP PDF for the OWASP Top Ten 2017 can be found here.