So analysieren Sie das CLDAP-Protokoll Reflection DDoS

Vorwort

Im ersten Halbjahr 2018 hat der Spitzenverkehr von DDoS dank des Reflexionsverstärkungsfaktors von Memcache von fast 50.000 eine beispiellose neue Höhe von 1,7 Tbit/s erreicht, was Memcache RedDoS auch zum Rückgrat des aktuellen DDoS macht. Im Vergleich zu Memcache RedDoS ist CLDAP RedDoS, das 2016 von Akamai veröffentlicht wurde, zwar nicht so effizient wie ersteres, sein 56- bis 70-facher Verstärkungsfaktor ist jedoch immer noch führend in der DDoS-Familie und sollte daher ebenfalls Aufmerksamkeit erregen.

1. CLDAP-Protokollfehler

Lightweight Directory Access Protocol (LDAP) ist in RFC2251 (LDAPv3) definiert. Da LDAP Daten in Form eines TCP-Byte-Streams überträgt, verbrauchen seine notwendigen Bindungsvorgänge und häufigen Datensuchabfragen mehr TCP Verbindungsressourcen bis zu einem gewissen Grad, daher veröffentlichte die IETF 1995 das verbindungslose Lightweight Directory Access Protocol (CLDAP). Das offizielle Dokument ist RFC1798 (im Jahr 2003 setzte RFC3352 CLDAP auf den historischen Status). In CLDAP werden nur drei Vorgänge bereitgestellt: searchRequest, searchResponse (searchResEntry und searchResDone) und subscribeRequest. Wenn die Authentifizierungsfunktion nicht bereitgestellt wird, kann der Client UDP-Datagramme verwenden, um eine Vorgangsanforderung an den LDAP-Server-Port 389 zu initiieren. Da der Server zwei Antwortnachrichten zurückgibt, „searchResEntry“ und „searchResDone“, nachdem der Client eine „searchRequest“ initiiert hat, führt die Ausführung dieses Vorgangs im Allgemeinen dazu, dass kleinere Datenpakete größere Datenpakete widerspiegeln. Dieser Fehler wird dann ausgenutzt, um DDoS-Angriffe mit Reflexionsverstärkung durchzuführen. .

2. Aktueller Status von CLDAP Reflection DDoS

Laut dem von Akamai SIRT veröffentlichten Bericht beträgt der höchste derzeit erfasste Spitzenverkehr von CLDAP ReDDoS 24 Gbit/s und das maximale Reflexionsmultiplikator beträgt das 70-fache. Da CLDAP nicht weit verbreitet ist, unterstützt die Open-Source-LDAP-Software openLDAP keine UDP-Protokollanfragen mehr. Tatsächlich ist das Active Directory (AD) von Windows-Servern derzeit der am häufigsten für CLDAP-ReDDoS-Angriffe ausgenutzte Dienst. Normalerweise wartet der AD-Dienst auf LDAP-Vorgangsanforderungen vom Client am TCP-Port 389 und verwendet außerdem das CLDAP-Protokoll am UDP-Port 389, um auf den RootDSE-Suchvorgang zu warten (der RootDSE-Eintrag wird erstellt, wenn der AD-Dienst konfiguriert ist). ermöglicht unbefugten Zugriff. Der authentifizierte Client fragt den Server nach seinem Konfigurationsstatus, seinen Funktionen und erweiterten Attributen ab (auch bekannt als „AD-Pinging“). Die AD-Dienst-Abhörports einiger Windows-Server werden dem öffentlichen Netzwerk ausgesetzt und dann zur Ausführung von RootDSE-Abfragen ausgenutzt, um verstärkte Reflection-DDoS-Angriffe zu generieren. Sicherheitsforscher haben Perl-Exploit-Skripte auf Exploit-DB aufgedeckt: Um die Sicherheitslücke zu bestätigen, können Sie auch das LDAP-Rootdse-Skript von Nmap verwenden, um

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

zu scannen. Es ist ersichtlich, dass der defekte Server RootDSE-Einträge, Eintragsattribute und andere Konfigurationsinformationen zurückgibt.

3. Verbesserung und Erkundung der öffentlichen Nutzlast

Für das RootDSE CLDAP ReDDoS-Exploit-Skript in Exploit-DB ist die Nutzlast:

Da LDAP und CLDAP die Daten beim Übertragen von Daten zunächst in LDAP-Nachrichten kapseln Mit BER unter ASN.1 codiert und dann übertragen. Wir können das Online-Tool ASN.1 Playground verwenden, um diese Nutzlast wiederherzustellen (bei der Wiederherstellung müssen Sie zuerst die ASN.1-Strukturdefinition der LDAP-Nachricht in RFC2251 kompilieren und laden). Sie können die von relevanten Forschern in GitHub definierte ASN-Datei direkt verwenden):

Es ist ersichtlich, dass es sich bei dieser Nutzlast um die BER-Codierung einer searchRequest-Operation handelt, die das erforderliche Attribut der Objektklasse der obersten Klasse abfragt. Nach dem Testen und Erfassen beträgt die durchschnittliche Reflexionsverstärkungseffizienz dieser Nutzlast etwa das 50-fache. Wenn die dekodierte LDAP-Nachricht jedoch erneut kodiert wird, werden Sie feststellen, dass die Anzahl der BER-Kodierungsbits reduziert ist und ein Teil davon fehlt im Vergleich zur öffentlichen Nutzlast. :

Wenn diese Codierung verfügbar ist, verringert sie die Länge der Nutzlast (Sie müssen am Ende als Ende der LDAP-Nachricht ein weiteres x00 hinzufügen):

Durch Vergleich Bei der ursprünglichen Nutzlast können Sie feststellen, dass der zusätzliche Teil der ursprünglichen Nutzlast (x30x84 ...) tatsächlich eine LDAP-Nachrichtenantwortnachricht ist. Daher wird davon ausgegangen, dass sie beim Codieren nicht in der Anforderungsnachricht erscheinen sollte, sodass sie vollständig sein kann entfernt (es ist nicht klar, was der ursprüngliche Autor des Skripts hier beabsichtigt hat). Nach der Testerfassung wurde festgestellt, dass die verbesserte 40-Byte-Nutzlast verfügbar ist und die Reflexionsverstärkungseffizienz auf durchschnittlich etwa das 73-fache steigern kann, was einer Steigerung von fast 18 % im Vergleich zu den von UScert veröffentlichten 56- bis 70-fachen Daten entspricht . Es ist derzeit in öffentlichen Kanälen verfügbar. Ich habe noch keine optimierte Nutzlast gefunden:

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

Das obige ist der detaillierte Inhalt vonSo analysieren Sie das CLDAP-Protokoll Reflection DDoS. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!