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)
