Shikata Ga Nai

Private? There is no such things.

How I was able to do Mass Account Takeoverを訳してみた

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, ('ω')ノ