Hello there, ('ω')ノ
大量アカウントの乗っ取りを行うことができた方法を。
脆弱性:
パスワードリセットの欠陥
記事:
https://rikeshbaniyaaa.medium.com/how-i-was-able-to-do-mass-account-takeover-bug-bounty-b279af1ce62b
今回の脆弱性は、Webサイトのパスワードリセットページにあって。
パスワードをリセットするには、ユーザは2つのことを要求して。
(ユーザ名と電子メール)
これはOTPベースのパスワードリセットメカニズムで。
下記の3つのステップがあって。
1.ユーザー名とメールアドレスを入力して
2.受け取ったOTPを入力して
3.新しいパスワードを入力して
最初は、ステップ2で応答操作を実行しようとして。
被害者のユーザ名とメールアドレスを入力して。
OTPとして123456を入力して、応答を下記のように変更して。
{“success”:”false”}
⇩
{“success”:”true”}
ウェブサイトは、ステップ3にリダイレクトして。
被害者のアカウントの新しいパスワードを入力することを許可されたので。
新しいパスワードを入力してEnterキーを押してみると。
「OTPが無効です」というエラーメッセージが。
ウェブサイトはステップ3でもOTP(123456)を検証していたので。
攻撃者の有効なOTPを入力するとどうなるかを知るために。
攻撃者の有効なOTPを入力してみるとパスワードは正常にリセットされて。
そして、被害者のメールアドレスと新しいパスワードで。
急いでログインしたもののログインできず。
攻撃者をOTPを入力したため、被害者のパスワードではなく。
攻撃者のパスワードがリセットされたようで。
リクエストは次のとおりで。
{“username”:”victim123", ⇦ 被害者のユーザ名
“email”:”victimemail@gmail.com”, ⇦ 被害者のメールアドレス
”newpass”:”Pass@443", ⇦ 攻撃者の新しいパスワード
”mfa”:”432521"} ⇦ 被害者の有効なOTP
リクエストの本文には被害者のメールアドレスとユーザ名のパラメータが。
含まれていましたが、まったく役に立たなかったので。
リクエストを再送信しても機能していて。
つまり、別のバグもあったということで。
新しいOTPが要求されるまで、OTPは無効にならず。
つまり、新しいOTPを要求しなくても、同じOTPを何度も再利用できるわけで。
さて、興味深い部分があって。
攻撃者が被害者のユーザ名と電子メールを必要としないことに気付いたので。
攻撃者は自分のユーザー名とメールアドレスを入力できて。
攻撃者がする必要があるのは、ステップ3で被害者のOTPを入力することだけで。
攻撃者はどのようにして被害者のOTPを取得するかというと。
レート制限は実装されていなかったので。
簡単にブルートフォースできて、ブルートフォーシングプロセス中に。
OTPが入力されたすべてのユーザのパスワードを変更できて。
欠点:
OTPは1時間で期限切れになったので。
攻撃者は、この1時間の間にOTPを要求した被害者のパスワードしか変更できず。
ただし、ユーザ名と電子メールを持っている場合は。
新しいOTPを要求してブルートフォースすることで。
被害者のパスワードを変更できて。
Best regards, ('ω')ノ