Shikata Ga Nai

Private? There is no such things.

How I chained P4 To P2 [Open Redirection To Full Account Takeover]を訳してみた

Hello there, ('ω')ノ

 

P4をP2にチェーンする方法[完全なアカウント乗っ取りへのオープンリダイレクト]を。

 

脆弱性:

 オープンリダイレクト

 アカウント乗っ取り

 

記事:

 https://infosecwriteups.com/how-i-chained-p4-to-p2-open-redirection-to-full-account-takeover-a28b09a94bf7

 

今回は、「リファラ応答によるトークンリーク」を報告して。

 

次に、「redirectUrl」のあるエンドポイントに気づき。

その問題を修正しているときに、いくつかの変更が加えられ。

HTTPリクエストに新しいパラメータが追加された後に。

RedurectUrlをgoogle.comに変更したものの。

そこでメールをチェックしている間、それはgoogle.comで注入されておらず。

しかし、そのリンクを開いた後、それは正常にgoogle.comにリダイレクトされて。

 

次に、RedirectUrl=がリセットトークンに反映されていることに気付いて。

これは、ホストヘッダーインジェクション、0authの欠陥に似ていますが。

シナリオが異なって。

 

オープンリダイレクトについて:

無効化されたリダイレクトの脆弱性は、ユーザが信頼できる。

Webサイトにあるリンクにアクセスしたときに。

攻撃者がユーザを信頼できないサイトにリダイレクトできる場合に発生して。

この脆弱性は、OpenRedirectとも呼ばれて。

 

この問題を再現する手順:

1.https://redacted.vulnsite.com/loginからログインし.

 [パスワードを忘れる]をクリックして。

 下記が脆弱なWebサイトのUIで。

 

 

2.次に、Burp Suiteを開いてリクエストを傍受し。

 「パスワードを忘れた」をクリックして、被害者の電子メールを入力して。

 そのリクエストをリピータに送信し、リクエストを次のように変更して。

 下記が、変更前のHTTPリクエストで。

 

 

 そして、ターミナルを開いて、下記のコマンドを実行してリクエストを受信して。

  python3 -m HTTP. server 80

 

 次に、HTTPリクエストでredirectUrlを127.0.01に変更して。

  {“redirectUrl”:”http://127.0.01/?reset-result={0}&reset-callback-uri={1}"}

 

 

3.被害者としてリセットリンクを開いたとき。

 http://127.0.01/Secret_reset_tokenにリダイレクトされて。

 

4.リセットリンクで得た応答を確認して。

 

これで、URL(https://redacted.vulnsite.com/Secret_reset_token)を。

そのリセットリンクに置き換えるだけでパスワードをリセットできて。

これで、完全なアカウントの乗っ取りにつながる新しいパスワードを設定できて。

 

脆弱性開示プログラムのいくつかの方法論を学び。

それを有料ベースのプログラムに適用することをお勧めして。

公的有料プログラムに直接移行すると、バグや重複が発生する可能性が低くなり。

フラストレーションにつながって。

プラットフォームの理解に時間をかけて。

たとえば、Bugcrowdはレート制限の問題を受け入れますが。

プログラムにもよりますが、Hackeroneは受け入れなかったりと。

プログラムのポリシーと範囲を注意深く読んで。

チェックリストを作成して適用し。

つまり、POSTをGETに変更することによるCSRF、パスワードリセットページのSQL。

ヘッダを変更することによるホストヘッダインジェクションなど。

 

Best regards, (^^ゞ