Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md

22 KiB
Raw Blame History

キャッシュ毒入れとキャッシュ欺瞞

htARTE（HackTricks AWS Red Team Expert） でAWSハッキングをゼロからヒーローまで学ぶ！

HackTricks をサポートする他の方法:


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

違い

Webキャッシュ毒入れとWebキャッシュ欺瞞の違いは何ですか？

  • Webキャッシュ毒入れでは、攻撃者はアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、このコンテンツがキャッシュから他のアプリケーションユーザーに提供されます。
  • Webキャッシュ欺瞞では、攻撃者はアプリケーションに別のユーザーに属する機密コンテンツをキャッシュに保存させ、その後、このコンテンツをキャッシュから取得します。

キャッシュ毒入れ

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

キャッシュ毒入れ攻撃の実行には、いくつかのステップが含まれます:

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

発見: HTTPヘッダーをチェック

通常、応答がキャッシュに保存されている場合、それを示すヘッダーがあります。どのヘッダーに注意を払うべきかを確認するには、この投稿をチェックしてください: HTTPキャッシュヘッダー。

発見: 400コードのキャッシュ

応答がキャッシュされていると思っている場合は、悪いヘッダーを送信して、ステータスコード400で応答されるはずのリクエストを試してみることができます。その後、通常通りにリクエストにアクセスし、応答が400ステータスコードである場合、脆弱性があることがわかります（DoS攻撃さえ実行できます）。
悪く構成されたヘッダーは、ヘッダーとして\:だけであるかもしれません。
これらの種類のステータスコードがキャッシュされていない場合もあるため、このテストは無意味になることがあります。

発見: キーのない入力を特定および評価

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
もう1つの興味深いヘッダーはVaryです。このヘッダーは、通常はキーにならないヘッダーでも、キャッシュキーの一部として扱われる追加のヘッダーを示すことがよくあります。したがって、攻撃対象の被害者のUser-Agentを知っている場合、その特定のUser-Agentを使用しているユーザーのキャッシュを毒することができます。
キャッシュに関連するもう1つのヘッダーは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>"

Cookieハンドリングの脆弱性を悪用するためのWebキャッシュ毒化の使用

Cookieはページのレスポンスにも反映される可能性があります。たとえば、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を正規化せずにキャッシュされるため、Webサーバーにリクエストが到達したときに行われました。

複数のヘッダーを使用してWebキャッシュ毒化の脆弱性を悪用する

時には、複数の未キー入力を悪用する必要があります。たとえば、X-Forwarded-Host を自分が制御するドメインに設定し、X-Forwarded-Scheme を http に設定すると、Open redirect を見つけることができます。サーバーがすべての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

HTTPリクエストスマグリングを悪用してHTTPキャッシュポイズニング攻撃を行う方法

HTTPリクエストスマグリングを悪用してWebキャッシュポイズニングを実行する方法について学びます。

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

Webキャッシュ脆弱性スキャナーを使用してWebキャッシュポイズニングを自動的にテストできます。多くの異なる技術をサポートし、高度にカスタマイズ可能です。

使用例：wcvs -u example.com


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

脆弱な例

Apache Traffic Server (CVE-2021-27577)

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

GitHub CP-DoS

コンテンツタイプヘッダーに誤った値を送信すると、405のキャッシュされた応答がトリガーされました。キャッシュキーにはクッキーが含まれていたため、認証されていないユーザーのみを攻撃することが可能でした。

GitLab + GCP CP-DoS

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

Rack Middleware（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 は text/css MIMEタイプ（_.css_ファイルに期待されるもの）ではなく、text/htmlコンテンツタイプを持っています。

HTTPリクエストスマグリングを悪用してキャッシュデセプション攻撃を実行する方法について学びます。

自動ツール

  • toxicache：Golangスキャナーを使用して、URLのリストでWebキャッシュポイズニングの脆弱性を見つけ、複数のインジェクション技術をテストします。

参考文献


Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築および自動化できます。
今すぐアクセスしてください： {% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

ゼロからヒーローまでAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！

HackTricksをサポートする他の方法: