Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to analyze the CLLDAP protocol Reflection DDoS, the quality of the article is high, so Xiaobian shares it for everyone to make a reference, I hope you have a certain understanding of related knowledge after reading this article.

preface

In the first half of 2018, thanks to Memcache's nearly 50,000 reflection magnification, peak DDoS traffic has reached an unprecedented new high of-1.7Tbps, which also makes Memcache ReDDoS the backbone of DDoS today. Compared with Memcache ReDDoS, Akamai's CLLDAP ReDDoS exposed in 2016 is not as efficient as the former, but its magnification of 56~70 times is still one of the best in the DDoS family, so it should also attract attention.

I. Defects in the CLDP protocol

Lightweight Directory Access Protocol (LDAP) is defined in RFC2251 (LDAPv3). Because LDAP transmits data in TCP byte stream, its necessary binding operations and frequent data search queries will consume more TCP connection resources to a certain extent. Therefore, the IETF published the Lightweight Directory Access Protocol for Connectionless in 1995. The official document is RFC1798 (RFC3352 sets CLDP to historical state in 2003). CLLDAP provides only three operations: searchRequest, searchResponse (searchResearchEntry and searchResearchDone), abandonRequest. Without authentication, clients can use UDP datagrams to initiate operation requests on LDAP server port 389. Since the server will return two response messages searchResEntry and searchResdone after the client initiates searchRequest, in general, executing this operation will have the effect of reflecting larger packets from smaller packets, and this defect will be used to amplify DDoS attacks by reflection.

Second, the status quo of CLDP Reflection DDoS

According to a report published by Akamai SIRT, the highest peak traffic of CLLDAP ReDDoS captured so far is 24Gbps, and the maximum reflection factor is 70 times. Because CLLDAP is not widely used, the open source LDAP software openLDAP no longer supports UDP requests. In fact, the service most exploited for CLLDAP ReDDoS attacks is Active Directory (AD), the Windows Server Active Directory service. Typically, AD services listen for LDAP requests from clients on TCP port 389 and also wait for rootDSE searches to be performed using the CLDP protocol on UDP port 389 (rootDSE entries are created at AD service configuration time and allow unauthenticated clients to query the server for configuration status, capabilities, and extended attributes, also known as "AD pings"). Some Windows servers have AD service listening ports exposed to the public network, which are then used to execute rootDSE queries to generate amplified reflection DDoS attacks. Security researchers have published Perl exploit scripts on Exploit-DB: This defect can also be scanned for confirmation using the ldap-rootdse script of Nmap:

nmap -Pn -sSU 389,636 --script ldap-rootdse

It can be seen that the defective server will return configuration information such as rootDSE entries and entry attributes.

III. Improvement and exploration of public Payload

For Exploit-DB rootDSE CLDP ReDDoS exploitation script, its Payload is:

Because LDAP and CLLDAP encapsulate the data into LDAPmessage body before transmitting it using BER under ASN.1, we can use ASN.1 Playground to restore the Payload (you need to compile and load the ASN.1 structure definition of LDAPmessage in RFC2251, or you can directly use the asn file defined by relevant researchers in GitHub):

You can see that this Payload is the BER encoding of a searchRequest operation that queries the objectClass mandatory attribute of the top class. Through the test capture, the Payload can achieve an average reflection amplification efficiency of about 50 times:

However, if the decoded LDAP message is re-encoded, it will be found that the number of BER encoding bits is reduced, and some parts are missing compared with the public Payload:

If this code is available, it will reduce the Payload length (you need to add a\x00 at the end of the LDAPmessage):

By comparing with the original Payload, it can be found that the extra part of the original Payload (\x30\x84...) is actually an LDAPmessage response message, so it is considered that it should not appear in the request message when encoding, so it can be completely removed (it is not clear what the original script author intends here). After the test capture, it is found that the improved 40-byte Payload is available, and the reflection amplification efficiency can be increased to about 73 times on average, which is nearly 18% higher than the 56~70 times data published by UScert. At present, no more streamlined Payload has been found in the public channel:

In fact, to get the leanest Payload, you have to go back to the protocol itself. From RFC2251, we can see that searchRequest has 8 fields, while the fields that receive custom character input are only baseObject, filter and attributes. Based on the 40-byte Payload above, we can still make a fuss about the filter field and attributes field.

By constructing the filter and attributes fields, we get a much leaner Payload of 31 bytes in length. The Payload can achieve an average reflection amplification efficiency of about 89 times, which is 41% higher than the data published by UScert. If Akamai captures the highest reflection packet size of 3662 bytes, the new Payload can achieve a maximum reflection amplification factor of 118 times, which will also refresh the currently known CLLDAP ReDDoS theoretical amplification factor:

IV. Analysis of influence surface

We found through a search comparison in ZoomEye that the defective Windows server had specific banner information:

0\x84\x00\x00\x00\x10\x02\x01\x01a\x84\x00\x00\x00\x07\n\x01\x00\x04\x00\x04\x00

Combined with each flag bit in the code, the banner information is very similar to the LDAP server bindResponse message code, so it is inferred that the reason for the banner information is that the server makes a binding operation response when the ZoomEye scanning engine scans the defective LDAP server and informs the client that the binding is successful, which is also a necessary operation before the client searchRequest:

There are 214673 records searched in ZoomEye using this banner rule, which is about 52.2% of the total number of LDAP servers (411527):

Considering that there will be configuration changes on different servers at different time nodes, we use 2015, 2016 and 2017 as a distinction, and use crawlers to collect the first 1000 pieces of data respectively to verify the effectiveness of server defects. The results are shown in the table below:

According to the proportion obtained, the total number of defective servers in the Internet can be estimated:

So we believe there are at least 20,000 Windows servers on the Internet that are at risk of being exploited for Cldap ReDDoS attacks, and of course this still depends on the data provided by ZoomEye, and there may be more. At the same time, we obtained the reflection data packets of 153 defective servers in these 3000 data pieces, of which the largest data packet length is 3208 bytes, the smallest data packet length is 1918 bytes, and the average packet length of 153 data packets is 2665 bytes. According to these captured data, the reflection magnification of CLLDAP ReDDoS at this stage should be between 62 and 103 times, and the average reflection magnification is about 86 times.

The following is an introduction to the defects of CLDP protocol and the status quo of reflection amplification DDoS attacks. At the same time, the attack payload that has been disclosed at present is discussed, and a more streamlined Payload is further explored. The reflection amplification factor of CLDP ReDDoS is increased from an average of 50 times to 86 times. Finally, ZoomEye is used to make statistics and analysis on the affected Windows servers in the Internet. Current CLLDAP ReDDoS attacks are mainly caused by defects in Windows Server Active Directory services. In terms of prevention, restrictions on port 389 and port 636 should be implemented first, that is, to ensure that ports are not leaked or client IP whitelist mechanism.

About how to analyze the CLLDAP protocol Reflection DDoS to share here, I hope the above content can be of some help to everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.