怎樣剖析CLDAP協議 Reflection DDoS

這篇文章將為大家詳細講解有關怎樣剖析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就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。