Shikata Ga Nai

Private? There is no such things.

CORS misconfig that worths USD200を訳してみた

Hello there, ('ω')ノ

 

200米ドル相当のCORSの設定ミスを。

 

脆弱性:

 CORSの設定ミス

 

記事:

 https://mikekitckchan.medium.com/cors-misconfig-that-worths-usd200-4696eda5ab4c


今回は、ターゲットをredacted.comと呼ぶことに。

このバグによって、攻撃者はCORSの誤った設定を利用して。

被害者からトークンを盗むことができるので。

攻撃者はそのトークンを使用して、被害者に代わって。

ターゲットの不正なサービスを利用できて。

 

バックグラウンド:

ほとんどの要求と応答をテストしたもののあまり興味深いものはなかったので。

Burp Suiteですべてのリクエストとレスポンスを再確認すると。

下記のリクエストの1つがCORSに対して脆弱であることに気付いて。

 

GET /token HTTP/1.1
Host: subdomain.redacted.com
Origin: www.redacted.com
Connection: close
Accept: */*
Cookies: some-Cookies=xxxxxxxxxxxx;

 

そして、応答は下記のようになって。

{"some_token": "xxxxxxxxxxxxxxxxxxxxxx"}

 

Originヘッダをwww.evil.comに変更しても。

このエンドポイントは、200の応答を返すので。

攻撃者は被害者のトークンを盗むことができて。

ただ、これをバグとして報告してもNAとしてクローズされる可能性があるので。

このトークンが何であるか。

そしてこれを使用してターゲットに影響を与える方法を理解する必要があって。

 

エスカレーション:

そのため、jsファイル、Webアプリ、トークンの名前、サブドメイン名などに。

関する要求/応答履歴の検索に何時間も費やして。

最後に、Webアプリで生成されたトークンに関連するJSファイルを見つけることに。

このファイルには、下記のようなJSONが含まれていて。

 {"unique_service": "subdomain.redacted.com"}

 

したがって、トークンはここで説明する「unique_service」にリンクされている必要があると思います。


ターゲットのドキュメントを読むとunique_serviceに使用率の制限があって。

ユーザは、無料の制限を超えてそのサービスを使用すると。

料金を支払う必要があって。

サービスは、下記を経由して到達することができて。

 subdomain2.redacted.com/service

 

提供されたトークンは、下記のようなリクエストで認証トークンとして機能して。

 

POST /service HTTP/1.1
Host: subdomain2.redacted.com
Authorization: Bearer <some_token>

 

また、subdomain2は認証トークンのみをチェックして。

ユーザのセッションはチェックしないこともわかったので。

攻撃者がトークンを盗むことができれば、攻撃者はユーザに代わって。

サービスを使用して、Webアプリの無料の制限をすべて消費することができるわけで。

 

エクスプロイト:

攻撃者は、悪用するために自分がホストしているWebサイトに。

下記のスクリプトを挿入するだけで。

 

<html> 
<body> 
<script>history.pushState('', '', '/')</script> 
<form action="https://subdomain.redacted.com/token"> 
<input type="submit" value="Submit request" /> 
</form> 
</body>
</html>

 

自分のWebサイトがevil.comであるとすると。

攻撃者は被害者をだまして、適切なログインセッションで。

redacted.comと同じブラウザでevil.comをクリックさせることができて。


次にevil.comは、https://subdomain.redacted.com/tokenにリクエストを送信して。

トークンを要求して。

被害者は、同じブラウザにログインしているので。

そのセッションCookieも検証のために送信されて。

ターゲットは、リクエストの発信元をチェックしないので。

トークンをevil.comに返して。

最後に攻撃者はトークンを使用して、被害者のサービスの無料制限を消費できて。


結果:

このバグのポイントは、行き詰まった場合は。

すべての要求/応答をもう一度調査してみることで。

各トークン/パラメータの目的を理解してみて。

時間をかけてWebアプリのロジックを理解して。

また、ターゲットのドキュメントを読むことは。

ターゲットをよりよく理解するために常に役立って。

 

Best regards, (^^ゞ