北京大学、清華大学、テキサス大学ダラス校の研究者チーム 新しいクラスの DoS 攻撃 - RangeAmp、HTTP ヘッダーの使用に基づく コンテンツ配信ネットワーク (CDN) を介してトラフィックの増幅を組織します。 この方法の本質は、多くの CDN での Range ヘッダーの処理方法により、攻撃者は CDN を介して大きなファイルから 724 バイトを要求できるが、CDN はファイル全体またははるかに大きなデータ ブロックをファイルからダウンロードすることです。キャッシュに配置されるターゲットサーバー。 このような攻撃中のトラフィック増幅の程度は、CDN に応じて 43330 ～ XNUMX 倍の範囲にあり、受信トラフィックで CDN に過負荷をかけたり、被害者のサイトへの最終通信チャネルの容量を削減したりするために使用される可能性があります。
Range ヘッダーを使用すると、クライアントはファイル全体を返す代わりに、ダウンロードするファイル内の位置の範囲を指定できます。 たとえば、クライアントは「範囲: bytes=0-1023」を指定すると、サーバーはデータの最初の 1024 バイトのみを送信します。 この機能は、大きなファイルをダウンロードするときに必要です。ユーザーはダウンロードを一時停止し、中断された位置から続行できます。 「bytes=0-0」を指定する場合、標準では、ファイルの最初のバイト「bytes=-1」、最後のバイト「bytes=1-」を 1 バイトからファイルの終わりまで指定するように指示されています。 0 つのヘッダーで複数の範囲を送信することができます (例: 「Range: bytes=1023,8192-10240-XNUMX」)。
さらに、プロキシとして使用される別の CDN 経由でトラフィックを転送するときにネットワーク負荷を増加させることを目的とした XNUMX 番目の攻撃オプションが提案されています (たとえば、Cloudflare がフロントエンド (FCDN) として機能し、Akamai がバックエンドとして機能する場合 ( BCDN）。 この手法は最初の攻撃と似ていますが、CDN ネットワーク内で局所的に行われるため、他の CDN 経由でアクセスするとトラフィックが増加し、インフラストラクチャの負荷が増大し、サービスの品質が低下します。
この考えは、攻撃者が「bytes=0-,0-,0-...」、「bytes=1-,0-,0-...」、または「bytes=1024,0-,0-,0-...」などの複数の範囲の Range リクエストを CDN に送信するというものです。 「バイト=-0、53-、7432-...」。 リクエストには多数の「XNUMX-」範囲が含まれており、ファイルが位置 XNUMX から最後まで返されることを意味します。 範囲解析の実装が間違っているため、最初の CDN が XNUMX 番目の CDN にアクセスするときに、範囲の重複や交差がある場合、「XNUMX ～」の範囲ごとに完全なファイルが送信されます (範囲は集計されず、順次反復されます)。攻撃者によって最初に送信されたリクエスト。 このような攻撃によるトラフィック増幅の程度は、XNUMX ～ XNUMX 倍の範囲に及びます。
研究中に、13 の CDN の動作が研究されました。
Akamai、Alibaba Cloud、Azure、CDN77、CDNsun、Cloudflare、CloudFront、Fastly、G-Core Labs、Huawei Cloud、KeyCDN、StackPath、Tencent Cloud。 調査したすべての CDN で、エンド サーバーに対する最初のタイプの攻撃が許可されました。 CDN 攻撃の 6 番目の亜種は 77 つのサービスに影響を及ぼし、そのうち 10 つは攻撃のフロントエンドとして機能する可能性があり (CDN7、CDNsun、Cloudflare、StackPath)、12 つはバックエンドとして機能する可能性があります (Akamai、Azure、StackPath)。 Akamai と StackPath で最大の利点が得られ、Range ヘッダーで 13 を超える範囲を指定できます。 CDN 所有者は約 XNUMX か月前にこの脆弱性について通知され、情報が一般に公開されるまでに、XNUMX の CDN のうち XNUMX が特定された問題を修正するか、修正する用意があると表明していました (StackPath サービスのみが応答しませんでした)。
出所： オープンネット.ru