LDAP, like many UDP based protocols, has the ability to send responses that are larger than the request. With UDP not requiring any handshake before data is sent, these protocols make ideal amplifiers for reflective distributed denial of service attacks. Most commonly, these attacks abuse DNS and we have talked about this in the past. But LDAP is another protocol that is often abused.
CLDAP has been on the radar for DDoS attacks at least since 2014 (likely earlier, but this is the earliest mention I found with a little bit of Google): https://us-cert.cisa.gov/ncas/alerts/TA14-017A . But as recent as in June, CLDAP was a component of major DDoS attacks ( https://blogs.akamai.com/2020/06/akamai-mitigates-sophisticated-144-tbps-and-385-mpps-ddos-attack.html )
Some of our honeypots have been seeing a small number of the reflected packets from these attacks. In investigating them, we noticed that many of them appear to come from exposed windows domain controllers. Windows domain controllers do use LDAP for active directory and support connectionless LDAP (CLDAP) out of the box. CLDAP is part of the issue here as it supports UDP.
A quick sample from a lab system:
A simple 39-byte request will cause a 3062-byte response.
Interestingly, we also see floods of SYN-ACK packets from systems scanning for CLDAP. This could be related to these systems being overloaded with traffic and responding to spoofed TCP requests for port 389 as well as UDP requests.
Here a quick Wireshark snapshot of the SYN-ACK responses. Note how they arrive in less than a second.
So what should you do? I do not know of a good reason to allow clear text LDAP (Port 389, not LDAP over TLS) across your perimeter. Close that port!
---Application Security: Securing Web Apps, APIs, and Microservices - SANS London June 2022
Sep 1st 2020
|Thread locked Subscribe||
Sep 1st 2020
1 year ago