Cache Poisoning via URL discrepancies
Last updated
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
これは、キャッシュプロキシとウェブサーバー間の不一致を悪用してキャッシュポイズニング攻撃を実行するために提案された技術の要約です。https://portswigger.net/research/gotta-cache-em-all
この攻撃の目的は、キャッシュサーバーに静的リソースが読み込まれていると誤認させることです。これにより、キャッシュサーバーはパスの一部をキャッシュキーとして保存しながらキャッシュしますが、ウェブサーバーは別のパスを解決して応答します。ウェブサーバーは、ユーザーに関する機密情報やXSSのような悪意のあるペイロードを保存する動的ページを読み込む実際のパスを解決します。
URLデリミタはフレームワークやサーバーによって異なり、リクエストのルーティングやレスポンスの処理に影響を与えます。一般的なオリジンデリミタには以下があります：
セミコロン：Springでマトリックス変数に使用されます（例：/hello;var=a/world;var1=b;var2=c → /hello/world）。
ドット：Ruby on Railsでレスポンス形式を指定します（例：/MyAccount.css → /MyAccount）。
ヌルバイト：OpenLiteSpeedでパスを切り詰めます（例：/MyAccount%00aaa → /MyAccount）。
改行バイト：NginxでURLコンポーネントを分離します（例：/users/MyAccount%0aaaa → /account/MyAccount）。
このプロセスに従って他の特定のデリミタが見つかるかもしれません：
ステップ1：キャッシュ不可のリクエストを特定し、それを使用して潜在的なデリミタを持つURLがどのように処理されるかを監視します。
ステップ2：パスにランダムなサフィックスを追加し、サーバーの応答を比較して、文字がデリミタとして機能するかどうかを判断します。
ステップ3：ランダムなサフィックスの前に潜在的なデリミタを導入し、応答が変わるかどうかを確認して、デリミタの使用を示します。
目的：キャッシュサーバーとオリジンサーバーのURLパーサーは、エンドポイントマッピングとキャッシュキーのためにパスを抽出するためにURLを正規化します。
プロセス：パスデリミタを特定し、文字をデコードしてドットセグメントを削除することでパスを抽出して正規化します。
異なるHTTPサーバーやプロキシ（Nginx、Node、CloudFrontなど）は、デリミタを異なる方法でデコードし、CDNやオリジンサーバー間で不一致を引き起こす可能性があります。例えば、ウェブサーバーがこの変換を行う場合、/myAccount%3Fparam → /myAccount?paramですが、キャッシュサーバーはパス/myAccount%3Fparamをキーとして保持する場合、不一致が生じます。
これらの不一致を確認する方法は、パスをエンコーディングなしで読み込んだ後、異なる文字をURLエンコーディングしてリクエストを送信し、エンコードされたパスの応答がキャッシュされた応答から来たかどうかを確認することです。
ドットが関与するパスの正規化は、キャッシュポイズニング攻撃にとって非常に興味深いです。例えば、/static/../home/indexや/aaa..\home/indexのように、一部のキャッシュサーバーはこれらのパスをそれ自体をキーとしてキャッシュしますが、他のサーバーはパスを解決し、/home/indexをキャッシュキーとして使用するかもしれません。
以前と同様に、これらのリクエストを送信し、応答がキャッシュから取得されたかどうかを確認することで、/home/indexへの応答がこれらのパスがリクエストされたときに送信された応答であるかどうかを特定するのに役立ちます。
いくつかのキャッシュサーバーは、応答が静的であると特定された場合、常に応答をキャッシュします。これは以下の理由によるかもしれません：
拡張子：Cloudflareは、以下の拡張子を持つファイルを常にキャッシュします：7z、csv、gif、midi、png、tif、zip、avi、doc、gz、mkv、ppt、tiff、zst、avif、docx、ico、mp3、pptx、ttf、apk、dmg、iso、mp4、ps、webm、bin、ejs、jar、ogg、rar、webp、bmp、eot、jpg、otf、svg、woff、bz2、eps、jpeg、pdf、svgz、woff2、class、exe、js、pict、swf、xls、css、flac、mid、pls、tar、xlsx
デリミタと静的拡張子を使用して動的応答をキャッシュさせることが可能で、例えば/home$image.pngへのリクエストは/home$image.pngをキャッシュし、オリジンサーバーは/homeで応答します。
よく知られた静的ディレクトリ：以下のディレクトリには静的ファイルが含まれているため、その応答はキャッシュされるべきです：/static、/assets、/wp-content、/media、/templates、/public、/shared
デリミタ、静的ディレクトリ、ドットを使用して動的応答をキャッシュさせることが可能で、例えば/home/..%2fstatic/somethingは/static/somethingをキャッシュし、応答は/homeになります。
静的ディレクトリ + ドット：/static/..%2Fhomeや/static/..%5Chomeへのリクエストはそのままキャッシュされるかもしれませんが、応答は/homeかもしれません。
静的ファイル：/robots.txt、/favicon.ico、/index.htmlのような特定のファイルは常にキャッシュされます。これは、/home/..%2Frobots.txtのように悪用される可能性があり、キャッシュは/robots.txtを保存し、オリジンサーバーは/homeに応答します。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
