怎樣剖析CLDAP協定 Reflection DDoS

前言

   2018年上半年，得益於Memcache近5萬的反射放大倍率，DDoS的峰值流量已經達到了一個前所未有的新高度—1.7Tbps，這也使得Memcache ReDDoS成為目前DDoS的中堅力量。而與Memcache ReDDoS相比，2016年Akamai曝光的CLDAP ReDDoS雖然沒有前者極高的效率，但是其56~70倍的放大倍數在DDoS家族中也依然是一名佼佼者，因此也應引起關注。

一、CLDAP協定缺陷

輕量目錄存取協定（LDAP）被定義在RFC2251（LDAPv3）中，由於LDAP是以TCP位元組流的方式進行資料傳輸，其必要的綁定操作和頻繁的資料搜尋查詢會在一定程度消耗較多的TCP連接資源，於是IETF在1995年發布了面向無連接的輕量級目錄訪問協議（CLDAP），官方文件為RFC1798（ 2003年 RFC3352將CLDAP置為歷史狀態）。在CLDAP中只提供三種操作：searchRequest、searchResponse （searchResEntry和searchResDone）、abandonRequest，在不提供驗證功能的情況下，用戶端可以使用UDP資料封包對LDAP伺服器389連接埠發起作業要求。由於客戶端啟動searchRequest後服務端將返回searchResEntry和searchResDone兩條應答訊息，一般情況下執行該操作將具有較小資料包反射出較大資料包的效果，此缺陷隨即被利用進行反射放大DDoS攻擊。

二、CLDAP Reflection DDoS的現狀

根據Akamai SIRT發布的報告，目前捕獲的CLDAP ReDDoS最高峰值流量為24Gbps，最大反射倍數為70倍。由於CLDAP未被廣泛運用，開源LDAP軟體openLDAP早已不再支援UDP協定的請求。事實上，目前進行CLDAP ReDDoS攻擊被利用最多的服務是Windows伺服器的活動目錄服務Active Directory（AD）。通常AD服務會在TCP連接埠389上監聽來自客戶端的LDAP操作請求，同時也會在UDP連接埠389上使用CLDAP協定來等待執行rootDSE的搜尋操作（rootDSE條目在AD服務設定時創建，且允許未經身份驗證的客戶端對伺服器的配置狀態、功能和擴充屬性進行查詢，也稱為「AD ping」）。有些Windows伺服器的AD服務監聽埠暴露在公網，進而被利用來執行rootDSE查詢產生放大反射DDoS攻擊，在Exploit-DB上已經有安全研究者公開了Perl利用腳本：。若要確認漏洞，也可以使用Nmap的ldap-rootdse腳本進行掃描

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

可見有缺陷的伺服器將會傳回rootDSE的項目、項目屬性等設定資訊。

三、對公開Payload的改進與探索

針對Exploit-DB中rootDSE CLDAP ReDDoS的利用腳本，其Payload為：

#由於LDAP和CLDAP在傳輸資料時是先將資料封裝成為LDAPmessage訊息體後使用ASN.1下的BER進行編碼後再傳輸的，我們可以使用線上工具ASN.1 Playground對此Payload進行還原（還原時需先編譯載入RFC2251中LDAPmessage的ASN.1結構體定義，也可以直接使用GitHub中相關研究者定義好的asn檔）：

可以看出此Payload是一次searchRequest操作的BER編碼，其對top類別的objectClass必選屬性進行查詢。經測試捕獲，此Payload 平均產生的反射放大效率約為50 倍

#但是如果將解碼出的LDAPmessage再重新編碼回去，會發現BER編碼位數減少，與公開的Payload相比缺少了一部分：

如果此編碼可用，將會降低Payload長度（需要在末尾再補一個\x00作為LDAPmessage結尾）：

透過與原始Payload相比較，可以發現原來Payload多出的部分（\x30\x84…）其實上是一段LDAPmessage回應訊息，因此在編碼時被認為不應出現在請求報文中，所以完全可以去掉（暫不清楚腳本原作者這裡的意圖）。測試捕獲後發現，改進後的這段40位元組的Payload可用，且可以將反射放大效率提升至平均73倍左右，相比UScert公佈的56~70倍數據提升了近18%，目前在公開渠道也暫未找到更精簡的Payload：

事实上，要得到最精简的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白名单机制。

以上是怎樣剖析CLDAP協定 Reflection DDoS的詳細內容。更多資訊請關注PHP中文網其他相關文章！