Comment analyser le protocole CLDAP Reflection DDoS

Avant-propos

Au premier semestre 2018, grâce au facteur d'amplification de réflexion de Memcache de près de 50 000, le pic de trafic DDoS a atteint un nouveau sommet sans précédent de 1,7 Tbps, ce qui fait également de Memcache ReDDoS l'épine dorsale du DDoS actuel. Comparé à Memcache ReDDoS, bien que CLDAP ReDDoS exposé par Akamai en 2016 ne soit pas aussi efficace que le premier, son facteur d'amplification de 56 à 70 fois est toujours un leader dans la famille DDoS, il devrait donc également attirer l'attention.

1. Défauts du protocole CLDAP

Le protocole LDAP (Lightweight Directory Access Protocol) est défini dans la RFC2251 (LDAPv3). Étant donné que LDAP transmet des données sous la forme d'un flux d'octets TCP, ses opérations de liaison nécessaires et ses requêtes de recherche de données fréquentes consommeront plus de TCP. ressources de connexion dans une certaine mesure, l'IETF a donc publié le protocole d'accès léger aux répertoires sans connexion (CLDAP) en 1995. Le document officiel est RFC1798 (en 2003, RFC3352 a défini CLDAP au statut historique) . Seules trois opérations sont fournies dans CLDAP : searchRequest, searchResponse (searchResEntry et searchResDone) et abandonRequest. Lorsque la fonction d'authentification n'est pas fournie, le client peut utiliser des datagrammes UDP pour lancer une demande d'opération sur le port 389 du serveur LDAP. Étant donné que le serveur renverra deux messages de réponse, searchResEntry et searchResDone, après que le client ait lancé une searchRequest, l'exécution de cette opération aura généralement pour effet de faire en sorte que des paquets de données plus petits reflètent des paquets de données plus gros. Cette faille est ensuite exploitée pour mener des attaques DDoS par amplification de réflexion. .

2. État actuel des DDoS de réflexion CLDAP

Selon le rapport publié par Akamai SIRT, le trafic de pointe le plus élevé de CLDAP ReDDoS actuellement capturé est de 24 Gbit/s et le multiple de réflexion maximum est de 70 fois. Étant donné que CLDAP n'est pas largement utilisé, le logiciel LDAP open source openLDAP ne prend plus en charge les requêtes du protocole UDP. En fait, actuellement le service le plus exploité pour les attaques CLDAP ReDDoS est l'Active Directory (AD) des serveurs Windows. Habituellement, le service AD ​​écoute les demandes d'opération LDAP du client sur le port TCP 389 et utilise également le protocole CLDAP sur le port UDP 389 pour attendre l'opération de recherche rootDSE (l'entrée rootDSE est créée lorsque le service AD ​​est configuré et autorise un accès non autorisé Le client authentifié interroge le serveur pour connaître son état de configuration, ses capacités et ses attributs étendus (également appelés « ping AD »). Les ports d'écoute du service AD ​​de certains serveurs Windows sont exposés au réseau public, et sont ensuite exploités pour exécuter des requêtes rootDSE afin de générer des attaques DDoS par réflexion amplifiées. Les chercheurs en sécurité ont divulgué des scripts d'exploitation Perl sur Exploit-DB : Pour confirmer la vulnérabilité, vous pouvez également utiliser le script ldap-rootdse de Nmap pour analyser

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

On peut voir que le serveur défectueux renverra les entrées rootDSE, les attributs d'entrée et d'autres informations de configuration.

3. Amélioration et exploration de la charge utile publique

Pour le script d'exploitation rootDSE CLDAP ReDDoS dans Exploit-DB, la charge utile est :

Étant donné que LDAP et CLDAP encapsulent d'abord les données dans des messages LDAP lors de la transmission des données, la charge utile est codé en utilisant BER sous ASN.1 puis transmis. Nous pouvons utiliser l'outil en ligne ASN.1 Playground pour restaurer cette charge utile (lors de la restauration, vous devez d'abord compiler et charger la définition de structure ASN.1 du message LDAP dans RFC2251, puis également. Vous pouvez directement utiliser le fichier asn défini par les chercheurs concernés dans GitHub) :

On peut voir que cette charge utile est l'encodage BER d'une opération searchRequest, qui interroge l'attribut requis de objectClass de la classe supérieure. Après test et capture, l'efficacité moyenne d'amplification de réflexion de cette charge utile est d'environ 50 fois. Cependant, si le message LDAP décodé est réencodé, vous constaterez que le nombre de bits de codage BER est réduit et qu'une partie est manquante. par rapport à la charge utile publique :

Si cet encodage est disponible, cela réduira la longueur de la charge utile (vous devez ajouter un autre x00 à la fin du message LDAP) :

En comparant avec la charge utile d'origine, vous pouvez trouver que la partie supplémentaire de la charge utile d'origine (x30x84...) est en fait un message de réponse au message LDAP, on considère donc qu'elle ne doit pas apparaître dans le message de demande lors de l'encodage, elle peut donc être complètement supprimé (on ne sait pas clairement ce que l'auteur original du script voulait ici). Après la capture du test, il a été constaté que la charge utile améliorée de 40 octets est disponible et peut augmenter l'efficacité de l'amplification par réflexion jusqu'à une moyenne d'environ 73 fois, soit une augmentation de près de 18 % par rapport aux données 56 à 70 fois publiées par UScert. . Il est actuellement disponible sur les chaînes publiques. Je n'ai pas encore trouvé de charge utile plus rationalisée : 

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!