Hello there, ('ω')ノ
興味深いアカウント乗っ取りの脆弱性を。
脆弱性：
IDOR
アカウントの乗っ取り
記事：
https://avanishpathak.medium.com/an-interesting-account-takeover-vulnerability-a1fbec0e01a
今回は、ログイン機能がバイパスされ、興味深いアカウントの乗っ取りにつながるを。
序章 ：
このアプリケーションの任意のユーザ／従業員のアカウントにアクセスできて。
アカウント乗っ取りの脆弱性とは、攻撃者がアプリケーションに。
存在する認証の欠陥を悪用することにより。
資格情報を必要とせずに被害者のアカウントを。
不正に完全に制御できるようにする脆弱性の一種で。
攻撃シナリオ：
アプリケーションにはOTP機能を備えたログインがあり。
ユーザーは認証フローの一部として登録された電子メールに。
送信された４桁のOTPを入力することでログインできて。
最初に頭に浮かんだのは４桁のOTPだったので、ブルートフォースでOTPを強制し。
被害者のアカウントにログインすることで。
これは、短いOTPを見るときに最初に頭に浮かぶ可能性があって。
また、アカウント乗っ取りの脆弱性に関連する以前の調査結果で遭遇した応答で。
OTPがリークされているかどうかをチェックして。
アプリケーションが１０回の間違った試行の後に。
HTTP 429 Too Many Requests応答を返していることに気付いて。
これは、レート制限メカニズムが設定されていることを意味して。
また、応答で共有されているOTPが見つからなかったため、運がなく。
これをさらに深く掘り下げて、認証フローを詳しく調べることに。
正しいOTPを入力すると、/login/signinで発行されたPOSTリクエストは。
次のようになって。
正しいOTP：
{“ email ”:“usermail@gmail.com”,“code”:XXXX }
POSTリクエストは２つのパラメータで構成されていて。
これは、ユーザの電子メールアドレスとその電子メールアドレスに。
送信されたOTPであり、ユーザが自分のアカウントに。
正常にログインできることを示して。
/login/signinリクエストがキャプチャされ。
メールパラメータを正しいOTP（攻撃者のメールアドレスに送信された）の。
組み合わせを持つ既存のより高い特権のユーザーのメールに変更すると。
次のようになって。
正しいOTP：
{“ email ”:“admin@example.com”,“code”:XXXX }
このアクションを実行することで、アプリケーションの有効なユーザの。
アカウントにログインできて。
これは、メールとOTPの結合が緩い場合で。
この脆弱性を報告すると２４時間以内にトリアージされ、修正されて。
実装された修正は、メールパラメータが/login/signinリクエストから削除され。
ログインしようとしているユーザに送信されたOTPのみを。
検証するチェックが行われて。
有効な発行者の電子メールにチェックが実装されていないため、脆弱性が存在して。
アプリケーションはバックエンドから送信されたOTPのみを検証していたため。
変更された電子メールアドレスで有効なOTPを提供すると。
その電子メールに登録されたアカウントにログインし。
完全にアクセスできるようになっていて。
Best regards, (^^ゞ
