DrDoS cyberattacks based on the LDAP protocol

After the preliminary study of denial of service (DoS) cyberattacks alongside any of their variants set out in the article “DrDoS characteristics and operation,” this new article is going to address how the LDAP protocol is used as a tool to develop a DrDoS variant of a DoS cyberattack.

LDAP

The Lightweight Directory Access Protocol, known by its acronym LDAP, is a set of application-level protocols the user uses to access information available in a remote directory service.

LDAP is therefore a network service with a client-server architecture based on the X.500 (1993) specifications to handle queries and requests about the entities registered on a network, such as users, printers, shared folders, machine or services.

- Figure 1. LDAP operation scheme. -

It works with a database with a hierarchical tree-shaped structure, where all the components on the system such as its characteristics are described using specific attributes for each type of object. Thus, when a user needs to use a printer, he/she just needs to send a query about the printer directory to obtain a list of those that can be used, which are available, their printing features and their locations. LDAP is therefore a fundamental network service for the similar operation of other important services that rely on it, such as email or network filing.

RFC 4510 specifies the operational features of this network service, which operates on the standard port 389 through TCP connections (the typical configuration), but also, albeit it is less common, it may use UDP communications, in the variant called CLDAP (Connection-less LDAP), whose specifications may be found in RFC 1798, which has been replaced by RFC 3352. Likewise, for LDAP from version 2 onwards, its communications may be encrypted by SSL tunnels, using port 636.

Attack vector

The attackers exploit the fact that the variant CLDAP does not require the identification of the end of the connection to launch a wave of requests to these exposed, pre-identified servers, in order to saturate the processing capacity and disable the directories of the system being targeted in the attack and of the network services that rely on LDAP at the same time.

To do so, they turn to botnet networks under the attackers’ control and manage to have the responses from the servers redirected towards the victim machine using IP spoofing, that is, by replacing the request’s source address with the IP address of the system they make the target of the attack.

- Figure 2. Schematic of the LDAP attack. -

The intermediate LDAP or CLDAP servers are used to reflect the cyberattack and are exploited to generate responses that include a greater volume of data than concerning the source request packets. For example, a source LDAP packet that has a size of a few bytes, such as looking up the users in a directory, becomes a response packet of several kilobytes in the victim when the intermediate server responds with a list of all the users registered in its system.

The amplification factor may be anything from 46 to 55 for attacks on TCP and from 56 to 70 for attacks on UDP. A simple arithmetical operation of multiplying the number of requests from a botnet by its amplification makes it possible to obtain a clear perspective on the traffic the victim system has to absorb to prevent its resources from collapsing.

In 2016, an attack launched from the botnet “Mirai” managed to produce traffic of 1.3 terabytes per second, which created major operational difficulties for the attacked systems, which were associated with the companies Twitter, WhatsApp and PayPal.

Prevention

First of all, it is necessary to detect whether an LDAP server is exposed on the Internet; to do so, you can perform a search in the firewall on port 389 on UDP. If this type of connection is allowed, it is necessary to verify whether there is any kind of filtering by source. If connections are allowed and filtering is disabled, the LDAP server will be vulnerable. To make this check, we will use the following command:

nmap -sV -sC -p 389

Once it has been verified that it is vulnerable, it is possible to prevent your own directory servers from being voluntarily used as part of the platform of a DrDoS attack using LDAP against a third party. To do this, it is recommended that the following guidelines be followed:

• Disable UDP communication for directory services. Any machine that has the LDAP service set at active (through UDP or CLDAP) is vulnerable to becoming a victim of this attack, hence deactivating UDP communication in LDAP is crucial if at all possible.
• Ask the Internet service provider (ISP) for anti-spoofing ISPs may reject portmap traffic with spoofed addresses, which are not accessible through the actual path of the package. This will prevent the own LDAP server from receiving and processing queries that are liable to be a DrDoS attack through this protocol.
• Deploy the LDAP servers behind firewalls. The firewall must be configured with rules to detect and filter requests directed by UDP to the LDAP server port. Likewise, it is recommendable to set an anti-spoofing IP configuration and set out rules that include “whitelists” of IP addresses authorised to connect with the LDAP server.
• Limit the visibility of the LDAP server on the Internet. Limit access to the servers through filtering of IP addresses that can access it, so that it is not “public”.
• Deployment of detection systems and blocking of intrusions (IDS/IPS). By means of Event Manager- and Security Information-type solutions (SIEM), it is possible to identify anomalies in LDAP traffic and detect them quickly to apply an immediate response that limits the impact of the attacks that may occur.
• Set out an action protocol for LDAP DrDoS incidents. Having a pre-established plan of action against this type of attack that allows for a quick and effective response will help avoid the complications and failures the attack could otherwise cause. To do so, INCIBE’s National Guide for the notification and management of cyber incidents may be taken as the starting point.
• Keep LDAP servers updated and patched. To prevent the exploitation of other vulnerabilities may lead to an attacker being able to launch an LDAP DrDoS attack on the equipment.

Detection and evidence

The signs of whether an LDAP server is participating in a DrDoS attack, may be found by checking for excessive consumption of the machine’s resources, as regards: use of the processor, RAM and disk access. The information provided by the machine health monitoring tools deployed in the infrastructure is very useful, such as PRTG, SolarWinds, Nagios, among others, are very for verifying this.

Evidence can also be found in the network monitoring alerts, mainly analysing traffic related to port 389.

In the LDAP logs, it is also possible to find traces of the incident in the event that it has gone unnoticed when the attack occurred and there are suspicions that it is occurring. The logs associated with the LDAP service are accessible depending on the platform of the operating system on which it is running and, therefore, it is necessary to look up the documentation for each platform (Microsoft and the Linux distributions) to know exactly how these audit logs are stored.

Response and recommendations

The pre-planned action and incident management protocols must be put into practice if a DrDoS attack is confirmed. It is advisable to include the following points in them:

• Review the source of source and destination IP addresses, destination ports, and URL addresses of the LDAP traffic. Gather all the useful information and report it to ISP, so that it can block it. The information can be extracted from the
• Blocking and filtering of unwanted traffic. The data collected previously may be used to configure filtering rules in firewalls and routers, in order to prevent requests from reaching the one’s own LDAP server. It is also advisable to contact the Internet and hosting, provider so that they apply additional in their area filters that block the installation of unauthorised traffic.
• Obtain technical assistance. Contact IT technical services suppliers that they had contracted or the leading public CERTs, such as INCIBE-CERT.

On the other hand, it is also important to act quickly, since the organisation may face complaints from the victim of the attack due to its repercussions.

The last step, once the attack has ceased and the service has been restored to normal, is to investigate what caused it, identify the possible vulnerabilities and set out an action plan to makes it possible to eliminate the system’s weaknesses or, at least, to reinforce the measures implemented to prevent it from recurring.