HTTP Response Smuggling / Desync
Last updated
Last updated
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
この投稿の技術は次のビデオから取得されました: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
まず、この技術はHTTPリクエストスムーグリングの脆弱性を悪用しますので、それが何であるかを知っておく必要があります：
この技術と一般的なHTTPリクエストスムーグリングの主な違いは、攻撃するのではなく、被害者のリクエストにプレフィックスを追加するのではなく、被害者が受け取るレスポンスを漏洩または変更することです。これは、HTTPリクエストスムーグリングを悪用するために1.5リクエストを送信する代わりに、プロキシのレスポンスキューを非同期化するために2つの完全なリクエストを送信します。
これは、レスポンスキューを非同期化することができるため、被害者の正当なリクエストからのレスポンスが攻撃者に送信されるか、攻撃者が制御するコンテンツを被害者へのレスポンスに注入することができます。
HTTP/1.1は、以前のリクエストを待つことなく異なるリソースを要求することを許可します。したがって、中間にプロキシがある場合、プロキシのタスクはバックエンドに送信されたリクエストとそこからのレスポンスの同期を維持することです。
しかし、レスポンスキューを非同期化するには問題があります。攻撃者がHTTPレスポンススムーグリング攻撃を送信し、最初のリクエストとスムーグリングされたリクエストへのレスポンスが即座に返されると、スムーグリングされたレスポンスは被害者のレスポンスキューに挿入されず、単にエラーとして破棄されます。
したがって、スムーグリングされたリクエストがバックエンドサーバー内で処理されるのに時間がかかる必要があります。そのため、スムーグリングされたリクエストが処理される頃には、攻撃者との通信は終了します。
この特定の状況で被害者がリクエストを送信し、スムーグリングされたリクエストが正当なリクエストの前に応答されると、スムーグリングされたレスポンスが被害者に送信されます。したがって、攻撃者は被害者によって「実行された」リクエストを制御します。
さらに、攻撃者がリクエストを実行し、被害者のリクエストに対する正当なレスポンスが攻撃者のリクエストの前に返されると、被害者へのレスポンスが攻撃者に送信されます。これにより、被害者へのレスポンスを盗むことになります（例えば、Set-Cookieヘッダーを含むことがあります）。
一般的なHTTPリクエストスムーグリングとのもう一つの興味深い違いは、一般的なスムーグリング攻撃では、目的が被害者のリクエストの先頭を変更して予期しないアクションを実行させることです。HTTPレスポンススムーグリング攻撃では、完全なリクエストを送信しているため、1つのペイロードに数十のレスポンスを注入することができ、数十のユーザーを非同期化させることができます。
正当なユーザーに対して数十のエクスプロイトをより簡単に配布できるだけでなく、これはサーバーにDoSを引き起こすためにも使用できます。
前述のように、この技術を悪用するには、サーバーに送信される最初のスムーグリングメッセージが処理されるのに多くの時間がかかる必要があります。
この時間のかかるリクエストは、被害者のレスポンスを盗むことを試みるだけであれば十分です。しかし、より複雑なエクスプロイトを実行したい場合、これはエクスプロイトの一般的な構造になります。
まず、HTTPリクエストスムーグリングを悪用する初期リクエスト、次に時間のかかるリクエスト、そして1つ以上のペイロードリクエストがあり、そのレスポンスが被害者に送信されます。
HTTPリクエストスムーグリングの既知のペイロードと同様に、被害者のリクエストを盗むことができますが、1つの重要な違いがあります：この場合、**レスポンスに反映されるコンテンツを送信するだけで済み、永続的なストレージは必要ありません。
まず、攻撃者は反映されたパラメータを末尾に持つ最終POSTリクエストを含むペイロードを送信し、大きなContent-Lengthを指定します。
次に、最初のリクエスト（青）が処理され、スリープ中のリクエストが処理されている間（黄色）、被害者から到着する次のリクエストが反映されたパラメータの直後にキューに追加されます：
その後、被害者はスリープ中のリクエストに対するレスポンスを受け取り、もしその間に攻撃者が別のリクエストを送信した場合**、反映されたコンテンツリクエストからのレスポンスが攻撃者に送信されます。
ここまでで、HTTPリクエストスムーグリング攻撃を悪用して、クライアントが受け取るレスポンスを制御する方法と、被害者のために意図されたレスポンスを盗む方法を学びました。
しかし、レスポンスをさらに非同期化することも可能です。
HEADリクエストのような興味深いリクエストがあり、これはレスポンスボディ内にコンテンツを持たないことが指定されており、GETリクエストのようにContent-Lengthを含む必要があります。
したがって、攻撃者がHEADリクエストを注入すると、次のようになります：
その後、青いリクエストが攻撃者に応答されると、次の被害者のリクエストがキューに追加されます：
その後、被害者はHEADリクエストからのレスポンスを受け取りますが、これはContent-Lengthを含むがコンテンツは全く含まれないものになります。したがって、プロキシはこのレスポンスを被害者に送信せず、何らかのコンテンツを待つことになります。実際には、これは攻撃者によって注入された黄色のリクエストへのレスポンス**になります：
前の例に従い、被害者が受け取るレスポンスのボディを制御できること、およびHEADレスポンスが通常そのヘッダーにContent-TypeとContent-Lengthを含むことを知っていると、次のようなリクエストを送信してXSSを引き起こすことができます。ページがXSSに対して脆弱でなくても：
前述のレスポンス非同期化コンテンツ混乱攻撃を悪用すると、キャッシュが被害者によって実行されたリクエストへのレスポンスを保存し、このレスポンスがXSSを引き起こす注入されたものであれば、キャッシュがポイズンされます。
XSSペイロードを含む悪意のあるリクエスト：
被害者に対する悪意のあるレスポンスで、キャッシュにレスポンスを保存するよう指示するヘッダーを含む：
この場合、「被害者」が攻撃者である場合、攻撃者は今や任意のURLでキャッシュポイズニングを実行できる**。なぜなら、悪意のあるレスポンスでキャッシュされるURLを制御できるからです。
この攻撃は前の攻撃に似ていますが、キャッシュ内にペイロードを注入するのではなく、攻撃者が被害者の情報をキャッシュ内に保存します：
この攻撃の目的は、再びレスポンスの非同期化を悪用して、プロキシが100%攻撃者生成のレスポンスを送信させることです。
これを達成するために、攻撃者はレスポンス内にいくつかの値を反映するウェブアプリケーションのエンドポイントを見つけ、HEADレスポンスのコンテンツ長を知る必要があります。
攻撃者は次のようなエクスプロイトを送信します：
最初のリクエストが解決され、攻撃者に返されると、被害者のリクエストがキューに追加されます：
被害者は**HEADレスポンス + 2番目のリクエストレスポンスのコンテンツ（反映されたデータの一部を含む）**をレスポンスとして受け取ります：
ただし、反映されたデータがHEADレスポンスのContent-Lengthに応じたサイズを持っていたため、レスポンスキュー内で有効なHTTPレスポンスを生成しました。
したがって、2番目の被害者の次のリクエストは、攻撃者によって完全に作成されたものをレスポンスとして受け取ります。レスポンスが攻撃者によって完全に作成されているため、攻撃者はプロキシにレスポンスをキャッシュさせることもできます。
AWSハッキングを学び、実践する:HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する: HackTricks Training GCP Red Team Expert (GRTE)
