🗂

記録的なDDoS攻撃をもたらしたHTTP/2のゼロデイ脆弱性（Blog翻訳記事）

2023/10/11に公開

すでにCloudfalreのCDN、SSL/TLS暗号化、HTTP DDoS、WAF、Bot Management、Rate Limiting、API Gateway、Page Shieldを用いている場合は問題ありません。
Cloudflare以外をお使いの場合は、ご利用のサービスプロバイダにご相談ください。
軽減策の素早い実装が困難な場合、HTTP/2, HTTP/3(QUIC)の通信を一度止めることでも暫定対策は可能です。

本日未明、CloudflareはGoogleおよびAWSとともに、「HTTP/2 Rapid Reset」攻撃と呼ばれる新たなゼロデイ脆弱性の存在を公表しました。この攻撃は、HTTP/2プロトコルの脆弱性を悪用し、甚大かつ大容量の分散型サービス拒否（DDoS）攻撃を発生させます。Cloudflareはここ数カ月間、1秒間に2億100万リクエスト（rps）を超える、これまでに観測された攻撃の3倍の規模の攻撃を含む、こうした攻撃の連鎖を緩和してきました。2023年8月末以降、Cloudflareは1,000万rpsを超える攻撃を1,100回以上緩和しており、当社のこれまでのDDoS記録である7,100万rpsを超える攻撃は184回に上ります。

このゼロデイにより、攻撃者はスイスアーミーナイフのような脆弱性を悪用し、被害者を攻撃するための重要な新しいツールを手に入れました。時には複雑で困難な攻撃もありましたが、クラウドフレアはゼロデイ脆弱性の影響を軽減するための専用技術を開発する機会を得ることができました。

HTTPのDDoS軽減にCloudflareを使用している場合は、既に対策は完了し保護されています。以下に、この脆弱性に関する詳細情報、および安全性を確保するためにできることに関するリソースと推奨事項を記載します。

攻撃を分解する： CSOが知っておくべきこと

2023年8月下旬、Cloudflareのチームは、インターネットとすべてのウェブサイトが機能する上で重要な基本プロトコルである標準HTTP/2プロトコルを悪用する、未知の脅威アクターによって開発された新たなゼロデイ脆弱性に気付きました。Rapid Resetと名付けられたこの斬新なゼロデイ脆弱性攻撃は、HTTP/2のストリームキャンセル機能を活用し、リクエストを送信して即座にキャンセルすることを何度も繰り返します。

この些細な「リクエスト、キャンセル、リクエスト、キャンセル」パターンを大規模に自動化することで、脅威行為者はHTTP/2の標準的な実装を実行しているあらゆるサーバーやアプリケーションにサービス拒否を発生させ、ダウンさせることができます。さらに、この記録的な攻撃について注意すべき重要な点は、およそ20,000台のマシンで構成される小規模なボットネットが関与していたことです。Cloudflareは、数十万台から数百万台のマシンで構成される、これよりも桁違いの規模のボットネットを定期的に検出しています。比較的小規模なボットネットが、HTTP/2をサポートするほぼすべてのサーバーやアプリケーションを無力化する可能性のある、このような大量のリクエストを出力したことは、この脆弱性が無防備なネットワークにとっていかに脅威であるかを強調しています。

脅威行為者はHTTP/2の脆弱性と同時にボットネットを使用し、これまでに見たことのない速度でリクエストを増幅させました。その結果、クラウドフレアのチームは断続的にエッジの不安定性を経験しました。私たちのシステムは圧倒的多数の着信攻撃を軽減することができましたが、その量は私たちのネットワーク内のいくつかのコンポーネントに過負荷をかけ、断続的な4xxおよび5xxエラーによって少数のお客様のパフォーマンスに影響を与えました。

これらの問題の緩和に成功し、すべてのお客様に対する潜在的な攻撃を食い止めた後、私たちのチームは直ちに責任ある情報公開プロセスを開始しました。私たちは、この脆弱性を一般に公開する前に、私たちのミッションを前進させ、私たちのネットワークに依存しているインターネットの大部分を保護するために、どのように協力できるかを確認するために、業界の同業者と話し合いを始めました。

この攻撃の技術的な詳細については、別のブログ記事で取り上げています： HTTP/2 Rapid Reset: 記録的な攻撃を分解する。

Cloudflareと業界はこの攻撃をどのように阻止しているのか？

完璧な情報開示は存在しません。攻撃を阻止し、新たなインシデントに対応するためには、組織やセキュリティチームは、侵入を想定した考え方をする必要があります。なぜなら、ゼロデイ、進化する新たな脅威行為者グループ、これまでに見たことのない斬新な攻撃やテクニックが常に存在するからです。

この "想定された侵害 "の考え方は、情報を共有し、このような場合にインターネットの安全を確保するための重要な基盤です。Cloudflareがこのような攻撃を経験し緩和している間、私たちは業界のパートナーとも協力し、業界全体がこの攻撃に耐えられることを保証するよう努めていました。

この攻撃を軽減する過程で、当社のクラウドフレアチームは、このDDoS攻撃を阻止するための新技術を開発・構築し、この攻撃や将来発生する大規模な攻撃に対する当社独自の軽減策をさらに改善しました。これらの取り組みにより、当社の全体的な攻撃軽減能力と回復力が大幅に向上しました。Cloudflareをご利用のお客様は、保護されていると確信しています。

この脆弱性が悪用されないようにするためのパッチを開発しているウェブサーバーソフトウェアのパートナーにも警告を発しました。

情報開示は決して1回で終わるものではありません。クラウドフレアの生命線は、より良いインターネットを確保することであり、それはこのような事例から生まれます。インターネットに広範な影響が及ばないよう、業界パートナーや政府と協力する機会を得ることは、規模や業種に関係なく、あらゆる組織のサイバー耐性を向上させる上で私たちの役割を果たすことになります。

HTTP/2 Rapid Resetとクラウドフレアへの記録的な攻撃の起源とは？

Cloudflareがこのような攻撃を最初に目撃した企業の1つであることは奇妙に思えるかもしれません。DDoS攻撃に対して世界で最も強固な防御を持つ企業を、なぜ脅威行為者が攻撃するのでしょうか？

現実には、Cloudflareは攻撃がより脆弱なターゲットに向けられる前に、しばしば攻撃を受けています。脅威行為者は、ツールを開発し、テストした上で、野放しにする必要があります。記録破りの攻撃手法を持つ脅威行為者は、その規模や効果をテストし理解することが非常に困難です。私たちはネットワーク・パフォーマンスについて透明性を共有しており、公開されているパフォーマンス・チャートから攻撃の測定値を得ることができるため、この脅威行為者はエクスプロイトの能力を理解するために私たちをターゲットにしていた可能性が高いのです。

しかし、このテストと攻撃を早期に発見する能力は、私たちの顧客と業界全体の両方に利益をもたらす攻撃に対する緩和策を開発するのに役立ちます。

CSOからCSOへ：何をすべきか？

私は(Blog執筆者）20年以上CSOとして、このような無数の情報開示や発表を受けてきました。しかし、Log4Jであれ、Solarwindsであれ、EternalBlue WannaCry/NotPetyaであれ、Heartbleedであれ、Shellshockであれ、これらのセキュリティ・インシデントには共通点があります。とてつもない爆発が世界中に波及し、業界や規模に関係なく、私が率いた組織を完全に混乱させる機会を作り出しているのです。
その多くは、私たちがコントロールできなかった攻撃や脆弱性でした。しかし、その問題が私のコントロールできるものから生じたか否かにかかわらず、私が主導して成功したイニシアチブの命運を分けたのは、このようなゼロデイ脆弱性やエクスプロイトが特定されたときに対応する能力でした。
ラピッド・リセットは今回とは違うかもしれない、と言いたいところだが、そうではない。私のように何十年もセキュリティ・インシデントを経験してきた者であろうと、今日が勤務初日であろうと、今こそ確実に保護し、サイバー・インシデント対応チームを立ち上げる時なのです。
我々は、できるだけ多くのセキュリティ・ベンダーに対応する機会を与えるため、今日まで情報を制限してきました。しかし、ある時点で、このようなゼロデイ脅威を公にすることが責任あることになります。そして今日がその日です。つまり、今日以降、脅威の主体はHTTP/2の脆弱性をほぼ認識することになり、それを悪用することは必然的に容易となり、防御側と攻撃側の間の競争（パッチを当てるのが先か、悪用するのが先か）が始まることになります。組織は、システムがテストされることを想定し、防御を確実にするための事前対策を講じるべきです。

私にとっては、この脆弱性はLog4Jのような脆弱性を彷彿とさせます。より多くの研究者や脅威行為者がこの脆弱性を実験するにつれて、さらに高度なバイパスを含む、さらに短いエクスプロイトサイクルの異なる亜種が見つかるかもしれません。

Log4Jのように、このようなインシデントの管理は、「パッチを当てて終わり」というような単純なものではありません。インシデント管理、パッチ適用、セキュリティ保護の進化を継続的なプロセスに変える必要があります。なぜなら、脆弱性の亜種ごとにパッチを適用しても、リスクは軽減されるが、解消されるわけではないからです。

憂慮するつもりはないが、単刀直入に言います。あなたの組織に何も起こらないようにするために、これを完全なアクティブ・インシデントとして扱って頂くことをお願いします。

新しい変革の基準への提言

セキュリティ上の出来事は、次と同じものは一つもないが、学ぶべき教訓はあります。CSOの皆さん、すぐに実行に移すべき私の提言は以下の通りです。今回の件だけでなく、今後何年にもわたって：

貴社の外部ネットワークおよびパートナー・ネットワークの外部接続を把握し、インターネットに接続されたシステムを以下の緩和策で修復する。
既存のセキュリティ保護と、攻撃を保護、検出、対応するための機能を理解し、ネットワークに問題があれば直ちに修正する。
トラフィックがデータセンターに到達すると、DDoS攻撃を軽減することが困難になるため、DDoS防御がデータセンターの外部にあることを確認してください。
アプリケーション（レイヤー7）に対するDDoS防御を確実に行い、Webアプリケーションファイアウォールを確実に導入してください。さらに、ベストプラクティスとして、DNS、ネットワークトラフィック（レイヤー3）、APIファイアウォールに対する完全なDDoS防御があることを確認してください。
インターネットに面したすべてのウェブサーバーに、ウェブサーバーとオペレーティングシステムのパッチが導入されていることを確認する。また、Terraformのビルドやイメージのようなすべての自動化機能が完全にパッチ適用されていることを確認し、古いバージョンのウェブサーバーが誤って安全なイメージ上で本番環境にデプロイされないようにする。
最後の手段として、脅威を軽減するためにHTTP/2とHTTP/3（おそらくこれも脆弱）をオフにすることを検討してください。 HTTP/1.1にダウングレードするとパフォーマンスに大きな問題が生じるため、これはあくまで最後の手段である。
セカンダリのクラウドベースのDDoS L7プロバイダを境界に設置し、弾力性を高めることを検討する。

Cloudflareの使命は、より良いインターネットの構築に貢献することです。DDoS防御の現状にご不安をお持ちのお客様には、DDoS攻撃成功の試みを軽減するために、当社のDDoS機能と回復力を無料で提供させていただきます。私たちは過去30日間、このような攻撃を撃退し、すでにクラス最高のシステムをさらに改良してきたため、お客様が直面しているストレスを知っています。