インターネット全体に広がる脆弱性が巨大なDDoS攻撃を可能に

出典: Postmodern Studio（Alamy Stock Photo経由）

研究者たちは、過去2年間で最も深刻なHTTP/2プロトコルの分散型サービス拒否（DDoS）脆弱性を発見しました。

2023年8月、正体不明の攻撃者が当時史上最大規模のDDoS攻撃を実行し、過去の記録的な攻撃をはるかに上回りました。この攻撃は「Rapid Reset」と呼ばれる当時新しい手法によって実現され、HTTP/2の実装における根本的な欠陥を突いたものでした。Rapid Resetはその後の秋に対応されました。

現在、テルアビブ大学の研究者たちはRapid Resetの修正を回避する方法を特定しました。この手法は「MadeYouReset」と名付けられ、攻撃者が世界中のウェブサイトの最大3分の1に対して再び大規模なサイバー攻撃を仕掛ける可能性が浮上していますが、問題の正確な範囲を特定するのは容易ではありません。

MadeYouReset手法

HTTP/2がHTTP1.1よりも明らかに進化した点は、同時に複数のリクエストとレスポンスのサイクルを処理できることです。以前は、クライアントとWebサーバーは1回に1つのリクエストとレスポンスしか処理できませんでしたが、現在では複数のデータストリームを同時に処理できます。

もちろん、同時ストリーム数が無制限であれば、攻撃者が悪用してサーバーに無限のデータストリームを送りつけ、DDoS攻撃を仕掛けることができてしまいます。そのため、HTTP/2には、過負荷状態のサーバーが受信ストリーム数を制限できるパラメータが含まれており、多くの実装ではデフォルトで最大100に設定されています。

Rapid Reset（CVE-2023-44487として追跡され、共通脆弱性評価システム（CVSS）で10点中7.5の「高」評価）は、リクエストのキャンセルを大量に送ることで100ストリームの制限を無効化しました。攻撃者は標的サーバーにリクエストを送り、すぐにキャンセルします。これは、ユーザーがリンクをクリックした後、読み込み前に戻るのと同じです。HTTP/2から見れば、新たなリクエスト用のストリームが空いたことになります。しかし、リクエストはHTTP/2を処理するプロトコルライブラリと、実際にレスポンスを生成するバックエンドの2層で処理されるため、サーバーはキャンセルされたリクエストの処理を継続し、新たなストリームが開かれてさらに多くのリクエストが発生することになります。

幸いにも、非常に単純かつ明白な修正方法がありました。クライアントがリクエストをキャンセルできる回数を制限することです。これはしばらくの間は十分でした。

MadeYouResetの巧妙な発見は、HTTP/2リクエストをキャンセルできるのはクライアントだけではないという点です。

通常のWebコンテンツを運ぶ「フレーム」以外にも、HTTP/2は「制御フレーム」も送信します。これはデータストリームの動作を制御する指示や設定です。攻撃者がまず有効なリクエストを送り、その後に無効な制御メッセージを送ると、サーバーは攻撃者の代わりにストリームをキャンセルします。このプロセスは繰り返し実行でき、Rapid Resetと同様の効果を生み出します。

MadeYouResetはCVE-2025-8671として公式に追跡されており、Rapid Resetと同じくCVSSで7.5の「高」評価です。また、HTTP/2の異なる実装に関連する場合は他のCVEでも追跡されています。例えば、NettyアプリケーションフレームワークではCVE-2025-55163として8.2の高評価ですが、F5 NetworksのBIG-IPアプリケーションデリバリーコントローラー（ADC）ではCVE-2025-54500として6.9の中程度の評価です。

HTTP/2スタックの修正

テルアビブ大学の研究者たちは、責任ある情報公開プロセスの中で100社以上のベンダーと連携しました。一部のベンダーは、Rapid Reset後にストリームやリソース管理を強化したことで、公開前からすでにMadeYouResetへの対策ができていました。Cloudflareによると、現在使用されているほとんどのHTTP/2実装がこのカテゴリに該当しますが、NettyやF5のBIG-IP、Apache Tomcat、h2o、Jettyなどは最近になって修正されました。

そして、テルアビブ大学のチーフストラテジーオフィサーであるヤニブ・ハレル氏によれば、第三のカテゴリも存在します。「問題を100%理解し、すぐに修正すると答えたベンダーと、問題は認識しているが自分たちの責任ではないとするベンダーに分かれます」と彼は述べています。

こうした周辺的なケースで対立を生む要因は、MadeYouResetへの対策方法が多岐にわたることです。例えば、クライアントやサーバーによってストリームがリセットされた場合、関連するバックエンド処理を即座に停止するようにすれば対策となります。しかし研究者たちは、この対策は言うほど簡単ではなく、技術的に実装が難しい上に、バックエンド処理の中断が新たなセキュリティリスクを生む可能性があると指摘しています。

また、ベンダーはサーバーへのHTTPリクエスト数に独自の制限を設けて、プロトコル自体の不備を補うこともできます。あるいは、HTTP/2ライブラリ層でサーバー発のストリームキャンセルに制限を設け、Rapid Resetのクライアント発キャンセル制限と同様の対策を取ることも可能です。

問題は、大手ベンダーは通常HTTP/2ライブラリとサーバーの両方を管理していますが、一部のサーバーはプロトコル処理に外部ライブラリを利用している点です。その場合、MadeYouResetはどちらの層でも解決できるため、「誰が責任を持つべきか、誰が解決すべきかという点で、ほとんど哲学的な問題のようでした」とハレル氏は振り返ります。

「脆弱なベンダーの100%がこの問題を解決したとは言えません」と彼は認めつつも、「この問題にさらされる可能性があった多くのベンダーには通知し、彼らは自分たちがすべきと考える対応を行いました。そして、業界の大手プレイヤーがこの問題を解決したことは確認しています」と述べています。