解き放たれた、新しい DDOS 攻撃ベクトル 35 GBPS の WSD 攻撃
※ このBlog 記事は2019.9.18にChad Seamanによって執筆されたAkamai Blog 記事を翻訳した内容を元に作成しています。
はじめに
Akamai Security Intelligence Response Team（SIRT）のメンバーは、WS-Discovery（WSD）と呼ばれる UDP 増幅テクニックを利用した新しい DDoS ベクトルについて調査してきました。
WSD をめぐる状況について公表されたのは最近ですが、複数の攻撃者がすでにこの DDoS 手法を攻撃の強化に利用し始めています。
Akamai SIRT は WSD の問題が公になる前から予備調査を進めていましたが、Akamai のお客様 1 社が標的となったため、WSD 攻撃の仕組みについて直接的な知識を得ることになりました。この攻撃はゲーム業界を標的としたもので、ピーク時の帯域幅は 35 Gbps に達しました。
インターネット上のデバイスへの WSD プロトコルの実装をさらに調査したところ、重大な懸念が浮上しました。SIRT の調査では、最大で元のバイトサイズの 15,300% の増幅率を達成できることがわかったのです。つまり、WSD はリフレクション増幅率に関する DDoS 攻撃順位の第 4 位に相当することになります。
この記事では、増幅の懸念と推定、プロトコル実装の欠陥、組織にとって可能な防御策など、WSD に関連した調査結果を記します。
WS-Discovery (WSD)とは？
参考までに、Wikipedia では次のように説明されています。
Web Services Dynamic Discovery（WS-Discovery）はローカルネットワーク上のサービスを探索するマルチキャスト・ディスカバリー・プロトコルを定義した技術仕様です。このプロトコルには TCP および UDP ポート 3702 と IP マルチキャストアドレス 239.255.255.250 が使用されます。その名が示すとおり、ノード間の実際の通信は、ウェブサービス標準、特に SOAP-over-UDP を使用して実行されます。
このプロトコルの目的は？
WSD は、コンシューマー・デバイス・ネットワークの探索と接続を簡単にするために開発されたテクノロジーの 1 つです。この分野の他のテクノロジー、たとえば Simple Service Discovery Protocol／Universal Plug and Play（SSDP／UPnP）やマルチキャスト DNS（mDNS）などとよく似た役割を果たしています。現在、SSDP／UPnP と mDNS はどちらもコンシューマー・ハードウェア・ベンダーのずさんな実装により、DDoS 攻撃に利用されています。
このプロトコルを利用している製品は？
WSD を使用している製品は多岐にわたります。Windows Vista 以降のデフォルトの機能セットおよびサービスとして出荷され、2008 年からは HP のプリンターにも搭載されてきました。インターネット上に不適切に露出され WSD に応答していることがわかったデバイスは、そのほとんどが防犯カメラと DVR システムでしたが、状況を考えればこの傾向は驚くことではありません。
問題点
UDP はステートレスプロトコルであるため、WSD サービスへの要求はスプーフィングが可能です。そのため、悪用されたサーバーまたはサービスが、標的になったユーザーにその応答を送信することで、標的の帯域幅が大量に消費されることになります。DDoS 攻撃には、実装に欠陥のある IoT サービスを利用するものが多く、これまでも大規模な攻撃で確認されてきました（2016 年の Dyn に対する攻撃など）。よく観察されるリフレクション DDoS タイプは他にもあり、2018 年には memcached を利用した 1.3 Tbps の攻撃が発生しています。
問題が生じた状況／原因
WSD が抱える問題は、これまで私たちが何度も見てきたものと同じです。WSD は LAN の範囲での使用を目的として設計されたテクノロジーであり、インターネット上での利用は想定されていませんでした。このサービスが（不適切に）実装されたハードウェアをメーカーが販売し、ユーザーがそのハードウェアをインターネット上に配置したため、意図せず新たな DDoS リフレクションベクトルが生じたのです。そしてこの攻撃ベクトルはすでに悪用され始めています。
ユニキャスト IP アドレスへの応答
WSD プローブは、LAN をスコープとするマルチキャストアドレス 239.255.255.250 を使用する設計になっています。これは LAN 上のマシンがパケットを 1 つ送信すると、そのパケットを同じサブネット上のすべてのホストが受信できるようにする特別なアドレスです。このパケットはインターネットの通過を想定したものではありません。ところが 本ケースにおけるWSD は、ユニキャスト IP アドレスの使用時、つまりネットワーク上の単一の受信者のみがパケットを受信している状況で、デーモンがこれらのプローブに応答しています。メーカーがこのテクノロジーを、適切なマルチキャストアドレス宛のパケットのみに応答するようにしていれば、この問題は発生しなかったと考えられます。
調査結果
WSD プロトコルを調査するにあたり、Akamai SIRT はインターネットでいくつかスキャンを実施し、この攻撃のさまざまな特徴を明らかにしようとしました。ここでは、プロービング、応答、メーカー／モデルの ID、情報漏えい、エコシステム、増幅率、プロトコル仕様など、調査からわかったことをまとめます。
プローブの利用目的
悪用ではなく、通常の状況で LAN 内のマシンが WSD プローブを使用するのは、ネットワーク上の利用可能なサービスのアナウンスや自動設定の支援のため、およびこれらのサービスをコンシューマーデバイスが利用できるようにするためです。たとえば、WSD は Window マシン（Vista 以降）が、ネットワーク接続されているプリンターを自動的に検出して設定する手段として使用されています。
プローブのサイズと応答
WSD サービスはデバイスの探索と通信に特定の Simple Object Access Protocol（SOAP）ペイロードを使用します。デフォルトのプローブペイロードは、サービス仕様書に記載され、サイズは 783 バイトです。
図 1 - プロトコル仕様書に基づく WSD のデフォルトプローブ
Akamai SIRT の調査で明らかになったこととして、このプローブは WSD ワーキンググループが定めた仕様に従ってうまく構成されているものの、冗長部分の多くを取り除くことが可能で、しかも、取り除いても「有効な」応答をトリガーできるのです。
こうして軽量化したプローブの最小有効サイズはわずか 170 バイトです。このような小さいサイズのプローブを使用すれば、攻撃者が発信に必要とする帯域幅が 400% 以上も圧縮されるため、可能な攻撃規模が著しく増大します。
ところが、この 170 バイトのプローブは、エンドポイントを識別したり攻撃を開始するための必要最小限のペイロードではありません。典型的な増幅攻撃では、最小量のデータを送信して最大量の応答をトリガーすることを目指します。このWSDのケースの場合、実際にこの比率が最大となるのは有効なリクエストの場合ではないのです。
攻撃者は 29 バイトの無効なペイロードを送信することで、WSD による XML エラー応答をトリガーできます。わずか 18 バイトのペイロードでこれが可能な場合もあります。18 バイトのプローブは、デフォルトプローブより 43%、最小有効プローブより 900% も小さいサイズです。トリガーされる応答も小さくなりますが、それでも増幅率は膨大になります。
増幅（Amplification）
一見しただけでは、WSD プロトコルの増幅は実際ほど大きなものには見えません。これは、不正な応答を生じさせるのに必要なデフォルトのプローブ／ペイロードのサイズが非常に大きいからです。しかし、Akamai SIRT のリサーチャーは、もっと小さいプローブを利用して潜在的な増幅率を 15,300% 以上に拡大できるようなケースをいくつか発見しました。
繰り返しになりますが、これは最大増幅率リストの第 4 位に相当する増幅率であり、WSD はリフレクション DDoS 攻撃に最も悪用されているいくつかのプロトコルと肩を並べることになります。以降では、WSD 攻撃の増幅シナリオと推定される DDoS の影響を説明します。
ペイロードの埋め込み
テストの過程で、WSD プローブペイロード内の MessageID フィールドを使用すると WSD プローブの応答に明らかな変化が生じることがわかりました。MessageID フィールドは、セッションの追跡と管理のメカニズムの一種として機能します。
つまり、MessageID に値があるペイロードをクライアントが送信すると、アプリケーションレイヤーで WSD が、その後該当クライアント／セッションに戻る応答にこの値を関連付けます。場合によっては、これが永続的なフィールドに変わることもあり、この方法を攻撃者が利用すると、その WSD サービスから戻る応答全体が拡大します。
MessageID 機能のバリエーション
MessageID フィールドの扱い方はデバイスやメーカーによって異なります。複数の要求に適用されるセッション関連の値としてこのフィールドを使っているデバイスもあれば、最初の応答で埋め込まれた値を返すだけの場合もあります。ほとんどのデバイスはこの値を 256 バイトに調節していますが、なかには攻撃者がこのフィールドに数キロバイトのデータを入れておける場合もあり、こうしたデータは最終的に応答に含まれることになります。
23:20:29.616596 IP Y.Y.Y.Y.3702 > X.X.X.X.56727: UDP, bad length 61648 > 1472
図 2 - 61 k が埋め込まれた応答を返すリフレクター
幸いなことに、こうしたデバイスのほとんどは複数の要求にわたってこの値を永続的にトラッキングすることはないようです。そのため、攻撃者がこのような大きなサイズの応答を発生させるためには要求に毎回、値を埋め込む必要があり、増幅はほとんど生じません。
MessageID の埋め込み、バッファオーバーフロー、増幅
これらの埋め込み機能をテスト中に、ある特定メーカーの 2,000 台を超えるデバイスの WSD プロトコル実装内に off-by-one エラーによるバッファオーバーフローが発見されました。これはプロトコルとデバイスにとって潜在的なセキュリティリスクとなります。このようなケースはこのブログ記事の範囲を超えていますが、大きな増幅ペイロードを形成するために利用される可能性があるため簡単に説明します。
悪用されたデバイスに、最初のプローブ値として 257 バイトを超える MessageID ペイロードが送信されると、応答の RelatesTo エレメントには最初のペイロードの 257 バイトが入ります。さらにバッファオーバーフローにより、ヌルバイトに当たるまで繰り返しメモリ内の次の値が含まれることになります。この場合、メモリ内の次の値は urn:uuid 値であり、これが応答の MessageID エレメントに入ります。
<wsadis:MessageID>AAA...A</wsadis:MessageID>
図 3 - MessageID ペイロードをトリガーするオーバーフローの例
<wsadis:MessageID>urn:uuid:31f83496-c857-11b2-80d9-54c4157e8d4b</wsadis:MessageID>
<wsadis:RelatesTo>AAA...Aurn:uuid:31f83496-c857-11b2-80d9-54c4157e8d4b</wsadis:RelatesTo>
図 4 - オーバーフロー例の結果
これにより最初のプローブのサイズは大きくなりますが、MessageID 値が応答内にコピーされるため、実際のリフレクト値は 46 バイト大きくなります。その結果、451 バイトのプローブペイロードによって 3,445 バイトの応答がトリガーされ、増幅率は 700% になります。
オーバーフローの埋め込みとスティッキーセッション
これらのデバイスでは、セッションはプローブ要求を開始したホストの IP アドレスにリンクされているように見えます。これはつまり、後続のリクエストでMessageID にペイロードが埋め込まれなくても、値が埋め込まれた応答をトリガーできるということです。
このシナリオでは、攻撃者は最小限のプローブ要求ペイロードを使用して、オーバーフロー埋め込み応答を受信できます。これにより、170 バイトの有効なプローブで 3,445 バイトの応答をトリガーすることも可能で、その増幅率は 2,000% を超えます。
17:45:54.632582 IP X.X.X.X.63186 > Y.Y.Y.Y.3702: UDP, length 170
17:45:54.905258 IP Y.Y.Y.Y.3702 > X.X.X.X.63186: UDP, bad length 3445 > 1472
17:45:54.905266 IP Y.Y.Y.Y > X.X.X.X: ip-proto-17 (UDP fragment)
17:45:54.906379 IP Y.Y.Y.Y > X.X.X.X: ip-proto-17 (UDP fragment)
図 5 - 20 倍の応答をトリガー
オーバーフローの埋め込み、スティッキーセッション、エラーによる 15,300% の増幅
WSD のスティッキーセッションは有効なプローブだけでなく、エラーにも適用されます。前述のとおり、WSD 対応ホストに送信できる最小ペイロードサイズは 18 バイトです。
この最小ペイロードでは有効な応答はトリガーされず、WSD サービスは "the xml format error (sic)" による /discovery/fault を示します。
このエラー応答では、オーバーフローの埋め込みを利用した有効応答の 3,445 バイトには届きませんが、エラー応答を 2,762 バイトにすることは可能であり、その場合の増幅率は 15,300% になります。
17:56:21.166839 IP X.X.X.X.53335 > Y.Y.Y.Y.3702: UDP, length 18
17:56:21.483838 IP Y.Y.Y.Y.3702 > X.X.X.X.53335: UDP, bad length 2762 > 1472
17:56:21.483847 IP Y.Y.Y.Y > X.X.X.X: ip-proto-17 (UDP fragment)
図 6 - 15,300% の応答をトリガー
増幅モデリングと見積り
こうした調査結果に基づき、一連の数値をまとめ、さまざまなシナリオについて帯域幅への影響の可能性を推定し、WSD 脅威の特性を明らかにしたいと思います。いずれのシナリオでも、攻撃者は 100 Mbps の帯域幅を使用可能であり、これをアップリンクに完全に利用できるものと想定しています。
オーバーフローの埋め込みによる増幅シナリオ
この例では、すべてのリフレクターが前述のオーバーフロー埋め込みペイロードとスティッキーセッションにさらされると想定します。現実にはこのような保証は不可能ですが、この例では合理的範囲で最悪のシナリオを示すことにします。
さらに、攻撃者は 1 つの埋め込みプローブペイロードでリフレクションエンドポイントを悪用できる状態にしたと想定します。これにより、3,445 バイトの有効な応答と 2,762 バイトのエラー応答が発生します。
攻撃者は脆弱なリフレクターに 100 Mbps のなりすまし要求を送信することで、大量のリフレクション DDoS トラフィックを生成できます。この攻撃者がデフォルトプローブ（783 バイト）を使用した場合、発生するリフレクション攻撃は 461 Mbps になります。同じ攻撃者がより小さい最小有効プローブ（170 バイト）を使用した場合、2 Gbps のリフレクショントラフィックを発生させることができます。最後に最悪のシナリオを考えてみます。同じ攻撃者が、オーバーフロー埋め込みエラー応答を返すようにコントロールされたホストに対して、「最小エラー」プローブ（18 バイト）を使用すると、16 Gbps のフラッディングが発生します。
幸いにも、スキャンによると、このシナリオに利用できる脆弱なリフレクタープールのデバイスは約 2,151 台にすぎず、それらはほぼ 2015 年にアジア市場で販売されたあるデバイスに関連しているようです。脆弱性が軽減された新たなバージョンの市場投入によってこれらのデバイスが廃止されることを願います。
平均的な増幅シナリオ
このシナリオでは、攻撃者は 6 万台を超えるデバイスからなるリフレクタープールを持ち、これらのデバイスは 29 バイトのペイロードに対して最大 2599 バイトのエラー応答を返すことができると想定します。テストでは 18 バイトのペイロードで比較的大きい増幅率を得ることができましたが、29 バイトのペイロードの方がより頻繁に応答をトリガーできることがわかりました。
私たちの計算では、29 バイトのペイロードの要求を 1 秒あたり 42 万件送信する攻撃なら、攻撃者が制御するシステムからの接続レートが 100 Mbits／s 未満で済みます。この場合、すべてのリフレクターが 2599 バイトのペイロードの応答を返したとしたら、攻撃の規模は 8.73 Gbits／s になります。
これは 8900% の増幅率です。
ノード数が 10 あれば、87 Gbps の攻撃が可能となります。
下記のサンプルでは、93 バイトの要求をテストし、2506 バイトのペイロードを受信しました。これは 26.95 倍、つまり 2,695% の増幅です。これはエラー応答のひとつのケースです。要求のサイズを 20 バイトに縮小すると、増幅率は 125.3 倍、つまり 12,530% になります。
図 7 - WSD 要求および 2506 バイトの XML エラーメッセージ
情報の漏えい
有効な XML 要求の送信時に、システムはデバイスの内部 IP アドレスとモデル番号を漏えいする可能性があります。この情報を使用してそのデバイスに対する既知の攻撃を調べれば、ネットワークへの足がかりを得ることができます。
要求サイズ 783 バイトでインターネット全体のスキャンを行ったところ、最も一般的な応答サイズは 1521 バイト（200% の増幅）でデバイス数は 23,723 でした。応答サイズの中央値（median）は 1517 バイト（193% の増幅）で、プローブに応答を返したデバイス数は 802,115 でした。
緩和
このような攻撃の緩和には DDoS イベントへの対策を計画する必要があります。UDP ソースポート 3702 をブロックすれば、このようなトラフィックはサーバーに届かなくなります。しかし、これで解決されるのは問題の半分にすぎません。依然として、このようなトラフィックはルータの帯域幅に輻輳をもたらします。そこに必要なのが、攻撃トラフィックをブロックするために必要な ACL を追加できる DDoS 緩和プロバイダーです。
Cisco スタイルの ACL
ipv4 access-list [ACCESS-LIST NAME] 1 deny udp any eq 3702 host [TARGET IP]
ipv4 access-list [ACCESS-LIST NAME] 2 deny udp any host [TARGET IP] fragments
Linux の iptables ACL
iptables -A INPUT -i [interface] -p udp -m udp --sport 3702 -j DROP
最後に
防犯カメラや DVR を使用され、重要な帯域を圧迫する WSD はインターネット上の大きなリスクです。今回もまた、セキュリティより利便性が優先された結果といえます。メーカーはポート 3702 の UDP プロトコルのスコープをマルチキャスト IP に制限できます。
今は、10～15 年と想定されるデバイスの耐用年数が尽きて、もっとセキュリティが強化されたバージョンに置き換えられるのを待つしかありません。
誰もが WSD 攻撃の標的となる可能性があります。組織は、このような大規模な攻撃を受けた場合にトラフィックを DDoS 緩和プロバイダーにルーティングするための準備をすべきです。増幅率が大きいため、WSD をリフレクションベクトルとして活用すれば攻撃者は労ぜずDDoSを実行できます。
その他の緩和策
Akamai Intelligent Edge プラットフォームは、このような「UDP 増幅」攻撃に対する防御機能を備えています。コネクションの確立が完了せず、トラフィックはオリジンには到達しません。
このタイプの DDoS 攻撃に対する、Prolexic（PLX）プラットフォームを介した防御については、お客様に以下のことをお勧めします。
- 攻撃時に Prolexic プラットフォームにルーティングする方法を確認します。
- 手順書が最新のものであること、正確であること、必要な連絡先とエスカレーション手順がすべて記載されていることを確認します。
- この脅威についてスタッフに注意喚起し、Akamai SOCC の利用方法をスタッフが理解していることを確認します。
- 過去 12 か月間に Security Services Primary によるサービス検証が実施されていない場合は、その実施スケジュールを決めます。
- その間、SOCC と協力して、Prolexic で予防的な 0 秒事前緩和 SLA を設定します。
- 警察または業界団体に攻撃を報告します。攻撃者の逮捕が世界の DDoS 攻撃ボリュームに影響を及ぼすことは明らかです。
