How to analyze CLDAP protocol Reflection DDoS

Preface

In the first half of 2018, thanks to Memcache’s reflection amplification factor of nearly 50,000, the peak traffic of DDoS has reached an unprecedented new height of 1.7Tbps, which also makes Memcache ReDDoS has become the backbone of current DDoS. Compared with Memcache ReDDoS, although CLDAP ReDDoS exposed by Akamai in 2016 is not as efficient as the former, its 56~70 times amplification factor is still a leader in the DDoS family, so it should also attract attention.

1. CLDAP protocol defects

Lightweight Directory Access Protocol (LDAP) is defined in RFC2251 (LDAPv3), because LDAP transmits data in the form of TCP byte stream , its necessary binding operations and frequent data search queries will consume more TCP connection resources to a certain extent, so the IETF released the connectionless lightweight directory access protocol (CLDAP) in 1995. The official document is RFC1798 ( 2003 RFC3352 sets CLDAP into historical status). Only three operations are provided in CLDAP: searchRequest, searchResponse (searchResEntry and searchResDone), and abandonRequest. When the authentication function is not provided, the client can use UDP datagrams to initiate an operation request to the LDAP server port 389. Since the server will return two response messages, searchResEntry and searchResDone, after the client initiates a searchRequest, generally performing this operation will have the effect of smaller data packets reflecting larger data packets. This flaw is then exploited to carry out reflection amplification DDoS attacks. .

2. Current status of CLDAP Reflection DDoS

According to the report released by Akamai SIRT, the highest peak traffic of CLDAP ReDDoS currently captured is 24Gbps, and the maximum reflection multiple is 70 times. Since CLDAP is not widely used, the open source LDAP software openLDAP no longer supports UDP protocol requests. In fact, currently the most exploited service for CLDAP ReDDoS attacks is the Active Directory (AD) of Windows servers. Usually the AD service will listen for LDAP operation requests from the client on TCP port 389, and will also use the CLDAP protocol on UDP port 389 to wait for the rootDSE search operation (the rootDSE entry is created when the AD service is configured, and allows unauthorized access The authenticated client queries the server for its configuration status, capabilities, and extended attributes (also known as "AD pinging"). The AD service listening ports of some Windows servers are exposed to the public network, and are then exploited to execute rootDSE queries to generate amplified reflection DDoS attacks. Security researchers have disclosed a Perl exploit script on Exploit-DB: To confirm the vulnerability, you can also use Nmap's ldap-rootdse script to scan

nmap -Pn -sSU 389,636 --script ldap-rootdse <target_ip>

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

3. Improvement and exploration of public payload

For the rootDSE CLDAP ReDDoS exploitation script in Exploit-DB, its payload is:

Since LDAP and CLDAP first encapsulate the data into an LDAP message body and then use BER under ASN.1 to encode the data before transmitting it, we can use the online tool ASN.1 Playground to restore this Payload (restore You need to first compile and load the ASN.1 structure definition of LDAP message in RFC2251, or you can directly use the asn file defined by relevant researchers in GitHub):

You can see This payload is the BER encoding of a searchRequest operation, which queries the obligatory attribute of objectClass of the top class. After testing and capturing, the average reflection amplification efficiency of this Payload is about 50 times

However, if the decoded LDAP message is re-encoded back, you will find that the number of BER encoding bits is reduced. , compared with the public Payload, a part is missing:

If this encoding is available, the Payload length will be reduced (an additional \x00 needs to be added at the end as the end of the LDAP message):

By comparing with the original Payload, you can find that the extra part of the original Payload (\x30\x84...) is actually an LDAP message response message, so it is encoded It is believed that it should not appear in the request message, so it can be removed completely (it is not clear what the original author of the script intended here). After test capture, it was found that the improved 40-byte Payload is available and can increase the reflection amplification efficiency to an average of about 73 times, which is an increase of nearly 18% compared to the 56~70 times data published by UScert. It is currently available in public channels. No more streamlined Payload has been found yet:

事实上，要得到最精简的Payload，还是要回到协议本身。从RFC2251中可以看出searchRequest操作共有8个字段，而接收自定义字符输入的字段只有baseObject、filter、attributes三个。在上述40字节Payload基础上，我们能继续做文章的依然是filter字段和attributes字段。

经过构造filter和attributes字段，我们得到了长度为31字节的更为精简的Payload。该Payload能达到均值约89倍的反射放大效率，相比UScert公布的数据又提升了41%，如果以Akamai捕获到的最高反射数据包大小3662字节计算，新的Payload能达到最高118倍的反射放大倍数，这也将刷新目前已知的CLDAP ReDDoS理论放大倍数：

四、影响面分析

我们在ZoomEye中通过搜索比较发现，存在缺陷的Windows服务器具有特定的banner信息：

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

结合编码中的每一个标志位来看，该banner信息与LDAP服务器bindResponse响应报文编码十分相似，因此推断出现该banner信息的原因，是由于ZoomEye扫描引擎在扫描到存在缺陷的LDAP服务器时服务器做出了一次绑定操作的响应，且告知客户端绑定成功，这也是在客户端searchRequest之前的必要操作：

使用此banner规则在ZoomEye中搜索共有214673条记录，约占所有LDAP服务器总数411527的52.2%：

考虑到不同服务器在不同时间节点上会出现配置上的变动，于是我们以2015、2016、2017这三年作为区分，使用爬虫分别采集前1000条数据对服务器缺陷进行有效性验证。结果如下表所示：

按照得出的占比，可以估算出目前互联网中存在缺陷的服务器总数：

因此我们认为，目前互联网中至少有2万台Windows服务器正处于被利用进行CLDAP ReDDoS攻击的风险之中，当然这仍然依赖于ZoomEye所提供的数据，真实情况可能有更多。同时，我们获取了这3000条数据中153台缺陷服务器的反射数据包，其中最大的数据包长度为3208字节，最小的数据包长度为1918字节，153个数据包平均包长度为2665字节。根据这些捕获到的数据，现阶段CLDAP ReDDoS的反射放大倍数应当处于62~103倍之间，平均反射放大倍数为86倍左右。

下面对CLDAP协议的缺陷及其造成反射放大DDoS攻击的现状进行了介绍，同时对目前已公开的攻击载荷Payload进行了探讨，并进一步探索出更精简的Payload，将CLDAP ReDDoS反射放大倍数从平均50倍提升至86倍，最后借助ZoomEye对互联网中受影响的Windows服务器进行了统计与分析。当前的CLDAP ReDDoS攻击主要是由于Windows服务器活动目录服务缺陷所引起，在防范上首先也应做到对389端口和636端口的限制，即确保端口不外漏或客户端IP白名单机制。

The above is the detailed content of How to analyze CLDAP protocol Reflection DDoS. For more information, please follow other related articles on the PHP Chinese website!