Following the Crumbs-Deconstructing the CLDAP DDoS Reflection Attack
When you work in Information Security, working with partial information is part of the job. One such example happened recently when Corero announced that they had discovered a new type of DDoS reflection attack. The only detail available from public sources was that it was related to abusing LDAP servers as an amplification vector. They claimed to see amplification in the 44x range, which means that the response size was 44 times bigger than the request. This had me scratching my head, isn’t LDAP TCP based? Most reflection attacks require UDP to forge the source IP to match the victim. And who leaves an LDAP server listening on the Internet?
LDAP is typically used on Windows Exchange servers and domain controllers. It provides directory and access control, so for instance, you can locate printers in a specific network, find a phone number of an employee, or find what security groups a user belongs to. There are many excellent resources online if you are looking for more details on Active Directory and its role in enterprise networks.
The first clue following Corero’s announcement was this post on Wireshark’s wiki. It was found after some googling involving the words “UDP”, “LDAP”, etc. Apparently, LDAP servers on Windows not only support TCP but also UDP, and LDAP over UDP is referred to as “CLDAP” or “Connectionless LDAP”. After further study, you discover that this type of query is used by clients to find further resources within a Windows network and what services are supported. The most popular uses of CLDAP is for something called a Netlogon query, more commonly referred to as a CLDAP “AD ping,” used as a basic discovery mechanism by Windows hosts. The next step was to find a tool to recreate this ping, and hopefully manipulate some responses into amplifying that query.
After quite a lot more googling (and discovering a lot of new LDAP specific terms), this piece of code from the samba team turned up. It is a basic capabilities poll of a domain controller, and sends what is known as a RootDSE or “Netlogon” request. Here is a screenshot of both the CLI output and what Wireshark sees:
Jackpot? Not quite. You’ll notice that response size is only 0.75 times bigger than the request. As a DDoS attacker, it would not be worth my while to use an amplification level so low. So how did they get to a 40+ increase in size that Corero reports?
The next step was figuring out what attributes aside from Netlogon could be queried from an LDAP server without authentication. For that, we’d want to go look at Microsoft’s site at the list of rootDSE attributes available to query. Stuffing all these attributes inside the samba’s example AD Ping script took some work, but after a while we ended up with a packet capture and response that looked like this:
Now we’re cooking with gas. We have an amplification factor of about 5.5x. Not yet at the 40x we are looking for, but moving in the right direction. At this point, trying to top those 3,000 bytes coming back from the server became more difficult. Microsoft has quite a large list of LDAP attributes, but they all seem to require authentication first. There are a few flags that can be manipulated to increase the packet size, but only by a few bytes. Then a light bulb went off. Instead of trying to increase the response size, how about we now try to decrease the request size?
To drive the request size down, we needed to figure out a way to represent these twenty-two attributes as one. How about using the old wildcard “*” character? LDAP already uses the wildcard to represent “anything” in other large queries of datasets, notably in the format (object=*), so this isn’t outside the realm of possibility. After crossing our fingers, we replace the twenty-two attributes above with an asterisk:
And we get the same sized response with only 63 bytes of effort, as opposed to more than 500 bytes previously. Doing the math, we’ve now created a 46x amplification flood! So now we’ve confirmed that we’ve found what we’ve been looking for, at ATI the next step is introduce it as an option for testing DDoS mitigation devices. In this case, we added support for multiple attributes and values as a JSON file. This file can be selected rather than using a static object and value pair for the response, which is more typical of normal traffic. Here’s what the pre-canned one we built for this upcoming release looks like:
And here is the packet capture from our Superflow confirming we have recreated the CLDAP flood correctly:
I hope you’ve enjoyed this trip following along with how we reverse-engineer and discover new ways of causing mayhem. If you’d like to know more about how to introduce this and thousands of other forms of chaos into your testing, please check out our BreakingPoint product line, where we deliver new releases every two weeks to make sure you are running the most current network attacks and applications across your environment.
Leverage Subscription Service to Stay Ahead of Attacks
The Ixia BreakingPoint Application and Threat Intelligence (ATI) Subscription provides bi-weekly updates of the latest application protocols and attacks for use with Ixia platforms.