hacktricks/pentesting-web/http-response-smuggling-desync.md
2023-07-07 23:42:27 +00:00

13 KiB
Raw Blame History

HTTPレスポンススミグリング/デシンク

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

HTTPリクエストキューデシンクロナイゼーション

まず、この技術はHTTPリクエストスミグリングの脆弱性を悪用するため、それが何であるかを知る必要があります。

この技術と一般的なHTTPリクエストスミグリングの主な違いは、攻撃者がプレフィックスを追加して被害者のリクエストを攻撃する代わりに、被害者が受け取るレスポンスを漏洩または変更することです。これは、HTTPリクエストスミグリングを悪用するために1つのリクエストと半分を送信する代わりに、2つの完全なリクエストを送信してプロキシのレスポンスキューを非同期化することによって行われます。

これは、レスポンスキューを非同期化することができるため、被害者の正当なリクエストのレスポンスが攻撃者に送信されるか、攻撃者がレスポンスに制御可能なコンテンツを注入することによって、被害者に送信されるレスポンスを攻撃者が制御することができるからです。

HTTPパイプラインデシンク

HTTP/1.1では、前のリソースを待つ必要なく、異なるリソースを要求することができます。したがって、プロキシ中間にある場合、プロキシの役割は、バックエンドに送信されたリクエストとそれに対するレスポンスの同期されたマッチを維持することです。

しかし、レスポンスキューを非同期化する問題があります。攻撃者がHTTPレスポンススミグリング攻撃を送信し、初期リクエストとスミグリングされたリクエストのレスポンスがすぐに返される場合、スミグリングされたレスポンスは被害者のレスポンスキューに挿入されず、エラーとして破棄されるだけです。

したがって、スミグリングされたリクエストがバックエンドサーバーで処理されるまでに時間がかかる必要があります

この特定の状況で、被害者がリクエストを送信し、スミグリングされたリクエストが正当なリクエストよりも先に応答される場合、スミグリングされたレスポンスが被害者に送信されます。したがって、攻撃者は被害者によって「実行される」リクエストを制御することができます。

さらに、攻撃者がリクエストを実行し、被害者のリクエストに対する正当なレスポンスが攻撃者のリクエストよりも先に応答される場合、被害者へのレスポンスが攻撃者に送信され、被害者のレスポンス(たとえばヘッダーSet-Cookieを含む)が盗まれます**。

複数のネストされたインジェクション

一般的なHTTPリクエストスミグリングとの興味深い違いは、一般的なスミグリング攻撃では、目標は被害者のリクエストの先頭を変更して予期しないアクションを実行することです。HTTPレスポンススミグリング攻撃では、完全なリクエストを送信するため、1つのペイロードに複数のレスポンスを注入することができ、これにより複数のユーザーが非同期化され、注入されたレスポンス受信することができます。

合法的なユーザーに対して複数のエクスプロイトをより簡単に配布することができるだけでなく、これはサーバーでのDoSを引き起こすためにも使用できます。

エクスプロイトの組織化

前述のように、この技術を悪用するには、サーバーに最初のスミグリングメッセージを送信するのに多くの時間がかかる必要があります

この時間のかかるリクエストは、被害者のレスポンスを盗むだけならば十分です。しかし、より複雑なエクスプロイトを実行したい場合は、この構造がエクスプロイトの一般的な構造になります。

まず、HTTPリクエストスミグリングを悪用する初期リクエスト、次に時間のかかるリクエスト、そして1つ以上のペイロードリクエストが続き、そのレスポンスが被害者に送信されます。

HTTPレスポンスキューデシンクの悪用

他のユーザーのリクエストのキャプチャ

HTTPリクエストスミグリングの既知のペイロードと同様に、**

レスポンスの非同期化

ここまで、HTTPリクエストスミグリング攻撃を悪用して、クライアントが受け取るレスポンスを制御し、その後、被害者向けのレスポンスを盗む方法を学びました。

しかし、レスポンスをさらに非同期化することも可能です。

HEADリクエストのような興味深いリクエストは、レスポンスボディにコンテンツが含まれないように指定されており、リクエストがGETリクエストであるかのようにContent-Lengthを含む必要があります(必須)。

したがって、攻撃者が次のようなHEADリクエストを注入する場合、次の被害者のリクエストがキューに追加されます:

その後、被害者HEADリクエストからのレスポンス受け取りますが、これにはContent-Lengthだけが含まれており、実際のコンテンツは含まれていません。したがって、プロキシはこのレスポンスを被害者に送信せず、実際にはコンテンツを待機します。このコンテンツは、攻撃者によって注入された黄色のリクエストに対するレスポンスです:

コンテンツの混乱

前の例に従って、被害者が受け取るレスポンスのボディを制御できること、およびHEADレスポンスが通常、ヘッダにContent-TypeとContent-Lengthを含むことを知っている場合、次のようなリクエストを送信して、ページがXSSに対して脆弱ではない状態で被害者にXSSを引き起こすことができます

キャッシュの汚染

先にコメントしたレスポンスの非同期化コンテンツの混乱攻撃を悪用すると、キャッシュが被害者によって実行されたリクエストのレスポンスを保存し、このレスポンスがXSSを引き起こすような注入されたものである場合、キャッシュが汚染されます

XSSペイロードを含む悪意のあるリクエスト

キャッシュに保存するようにキャッシュに指示するヘッダを含む被害者への悪意のあるレスポンス:

{% hint style="warning" %} この場合、「被害者」が攻撃者である場合、攻撃者は悪意のあるレスポンスでキャッシュされるURLを制御できるため、任意のURLでキャッシュの汚染を実行できます。 {% endhint %}

ウェブキャッシュの欺瞞

この攻撃は前の攻撃と似ていますが、キャッシュ内にペイロードを注入する代わりに、攻撃者はキャッシュ内に被害者の情報をキャッシュします

レスポンスの分割

この攻撃の目的は、再びレスポンスの非同期化を悪用して、プロキシが100%攻撃者が生成したレスポンスを送信することです。

これを実現するために、攻撃者はレスポンス内のいくつかの値を反映させるWebアプリケーションのエンドポイントを見つけ、HEADレスポンスのコンテンツ長を知る必要があります

攻撃者は次のようなエクスプロイトを送信します:

最初のリクエストが解決され、攻撃者に送り返された後、被害者のリクエストがキューに追加されます:

被害者は、HEADレスポンスと**2番目のリクエストのレスポンスのコンテンツ反映されたデータの一部を含む**をレスポンスとして受け取ります:

ただし、反映されたデータはHEADレスポンスのContent-Lengthに応じたサイズを持っていたことに注意してください。これにより、2番目の被害者の次のリクエストは、攻撃者によって完全に作成されたレスポンス受け取ることになります。レスポンスが攻撃者によって完全に作成されているため、攻撃者はプロキシがレスポンスをキャッシュすることもできます。

参考文献

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥