Shikata Ga Nai

Private? There is no such things.

Account Takeover by OTP bypassを訳してみた

Hello there, ('ω')ノ

 

OTPバイパスによるアカウントの乗っ取りを。

 

脆弱性:

 情報漏えい

 サーバ側セキュリティのクライアント側強制

 OTP バイパス

 アカウント乗っ取り

 

記事:

 https://codewithvamp.medium.com/account-takeover-by-otp-bypass-ec0cff67f516

 

実際に教師のログインと教育関連のものを扱っているこのウェブサイトを。

「example.com」と呼ぶことに。

 

 

教師としてログインするには、登録済みの携帯電話番号を入力する必要があって。

家族には教育部門のメンバーがいるので、彼らの番号を試してみると。

完全に確認した後、ログインすることができて。

 

次に、この検証プロセスをバイパスしてみようと思って。

Webアプリケーションのスクリプトで連絡先番号を取得することができて。

 

 

先生のログインをクリックして、スクリプトで見つけた。

連絡先番号(被害者の番号など)を入力して。

 

 

「確認」ボタンをクリックした瞬間、OTPを送信するための新しい画面が表示され。

(携帯電話番号を入力して[確認]をクリックすると。

 このポータルに教師として登録されていないため、続行できず)

[OTPの送信]をクリックすると、OTPは被害者の番号に到達しますが表示されず。

 

 

Burp Suiteでリクエストをインターセプトして、レスポンスがOTPを。

リークしているかどうかを確認しようとしましたが、うまくいかず。

次に、同じページの検査要素を開いて、携帯電話番号フィールドを調べると。

スクリーンショットでわかるように、携帯電話番号フィールドが。

「無効」になっていることを示しているので。

ステータスを「有効」に変更し、携帯電話番号を編集することができて。

 

 

この時点で、すでに被害者の携帯電話番号で確認されているので。

必要なのは、さらに先に進むためのOTPだけで。

携帯電話番号フィールドを有効にした後、被害者の携帯電話番号を。

自分の携帯電話番号に変更し、「OTPを送信」ボタンを押すと。

 

 

自分の番号でOTPを受け取ったので、すぐにOTPに入って。

 

 

 

 

OTPに入った瞬間、完全なアクセス権で被害者のアカウントにログインして。

 

 

 

Webアプリケーションの問題:

 1.携帯電話番号はスクリプトで公開されていて。

 2.「確認」プロセスはサーバ側で携帯電話番号を検証していますが。

  「OTPの送信」は検証されていないため。

  自分の番号でOTPを取得することになって。

 3.さらに試してみると、アプリケーションはOTPブルートフォーシングに。

  対しても脆弱で。

 

Best regards, (^^ゞ