剖析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腳本也可以對該缺陷進行掃描確認：

可見存在缺陷的伺服器將會返回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多出的部分（x30x84…）其實上是一段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信息：

結合編碼中的每一個標誌位來看，該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白名單機制，更多關於LDAP伺服器的安全實踐也可以參考 Best Practices in LDAP Security。

*本文作者：斗象能力中心TCC-S4kur4，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！