CLDAPプロトコルのリフレクションDDoSを解析する方法

はじめに

2018 年上半期、Memcache の約 50,000 の反射増幅率のおかげで、DDoS のピーク トラフィックは 1.7Tbps という前例のない新たな高さに達し、これにより Memcache の ReDDoS も可能になりました。現在の DDoS のバックボーンとなっています。 Memcache ReDDoS と比較すると、2016 年に Akamai が公開した CLDAP ReDDoS は前者ほど効率的ではありませんが、56 ～ 70 倍の増幅率は依然として DDoS ファミリーのリーダーであるため、こちらも注目を集めるはずです。

1. CLDAP プロトコルの欠陥

Lightweight Directory Access Protocol (LDAP) は、必要なバインディングである TCP バイト ストリームの形式でデータを送信するため、RFC2251 (LDAPv3) で定義されています。操作や頻繁なデータ検索クエリはある程度多くの TCP 接続リソースを消費するため、IETF は 1995 年にコネクションレス型軽量ディレクトリ アクセス プロトコル (CLDAP) をリリースしました。公式文書は RFC1798 です (2003 年の RFC3352 は CLDAP を歴史的な地位に設定しました)。 CLDAP では、searchRequest、searchResponse (searchResEntry および searchResDone)、abandonRequest の 3 つの操作のみが提供されます。認証機能が提供されていない場合、クライアントは UDP データグラムを使用して、LDAP サーバー ポート 389 への操作リクエストを開始できます。クライアントが searchRequest を開始した後、サーバーは 2 つの応答メッセージ searchResEntry と searchResDone を返すため、一般にこの操作を実行すると、より大きなデータ パケットをより小さなデータ パケットが反映する効果があり、この欠陥はリフレクション増幅 DDoS 攻撃の実行に悪用されます。 。

2. CLDAP Reflection DDoS の現状

Akamai SIRT が発表したレポートによると、現在捕捉されている CLDAP ReDDoS の最高ピークトラフィックは 24Gbps です。最大反射倍数は70倍です。 CLDAP は広く使用されていないため、オープン ソース LDAP ソフトウェア openLDAP は UDP プロトコル要求をサポートしなくなりました。実際、現在、CLDAP ReDDoS 攻撃に最も悪用されているサービスは、Windows サーバーの Active Directory (AD) です。通常、AD サービスはクライアントからの LDAP 操作リクエストを TCP ポート 389 でリッスンし、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 エントリ、エントリ属性、その他の設定を返すことがわかります。情報。

3. パブリック ペイロードの改善と調査

Exploit-DB の rootDSE CLDAP ReDDoS 悪用スクリプトのペイロードは次のとおりです:

LDAP と CLDAP は最初にデータを LDAP メッセージ本文にカプセル化し、送信する前に ASN.1 の下で BER を使用してデータをエンコードするため、オンライン ツール ASN.1 Playground を使用してこのペイロードを復元できます (最初に復元する必要があります)。 RFC2251 の LDAP メッセージの ASN.1 構造定義をコンパイルしてロードするか、GitHub の関連研究者によって定義された asn ファイルを直接使用できます):

これを確認できます。 payload は、最上位クラスの objectClass の必須属性をクエリする searchRequest オペレーションの BER エンコーディングです。テストしてキャプチャした後、このペイロードの平均反射増幅効率は約 50 倍です。

# ただし、デコードされた LDAP メッセージを再エンコードすると、 BER エンコーディング ビットの数が減少します。公開ペイロードと比較して、一部が欠落しています:

このエンコーディングが利用可能な場合、ペイロードの長さは減少します (追加の\x00 を LDAP メッセージの最後として末尾に追加する必要があります):

元のペイロードと比較すると、元のペイロードの余分な部分が見つかったことがわかります。ペイロード (\x30\x84...) は、実際には LDAP メッセージの応答メッセージであるため、エンコードされています。 要求メッセージには表示されるべきではないと考えられているため、完全に削除できます (元の作成者が何であるかは不明です)ここで意図したスクリプトの内容です)。テストキャプチャ後、改善された40バイトのペイロードが利用可能であり、反射増幅効率を平均約73倍に高めることができることが判明しました。これは、UScertが公開した56～70倍のデータと比較して、ほぼ18%の増加です。 . 現在、パブリック チャネルで利用可能です。これ以上合理化されたペイロードはまだ見つかりません:

事实上，要得到最精简的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プロトコルのリフレクションDDoSを解析する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。