shikata ga nai

Private? There is no such things.

An Interesting Account Takeover Vulnerabilityを訳してみた

Hello there, ('ω')ノ

 

興味深いアカウント乗っ取りの脆弱性を。

 

脆弱性:

 IDOR

 アカウントの乗っ取り

 

記事:

 https://avanishpathak.medium.com/an-interesting-account-takeover-vulnerability-a1fbec0e01a

 

ログイン機能がバイパスされて、興味深いアカウントの乗っ取りにつながることに。

今回、アプリケーションの任意のユーザ/従業員のアカウントにアクセスできて。

 

アカウント乗っ取りの脆弱性とは。

攻撃者がアプリケーションに存在する認証の欠陥を悪用することで。

資格情報を必要とせずに被害者のアカウントを。

不正に完全に制御できるようにする脆弱性の一種で。

 

攻撃シナリオ:

アプリケーションには、OTP機能を備えたログインがあって。

ユーザは、認証フローで登録された電子メールに。

送信された4桁のOTPを入力することでログインできて。

 

f:id:ThisIsOne:20210821101012p:plain

 

最初に頭に浮かんだのは4桁の短いOTPだったので。

OTPをブルートフォースして、被害者のアカウントにログインを試行すると。

アプリケーションが10回の間違った試行の後に。

HTTP 429 Too Many Requestsの応答を返していることに気付いて。

レート制限メカニズムが設定されていることを意味しており。

応答でOTPが見つけることができず。

 

これをさらに深く掘り下げて、認証フローを詳しく調べることに。

正しいOTPを入力すると。

/login/signinで発行されたPOSTリクエストは、下記のとおりで。

 

f:id:ThisIsOne:20210821100930p:plain

 

POSTリクエストは2つのパラメータで構成されていて。

 {“ email ”:“usermail@gmail.com”,“code”:<正しい4桁のOTP> } ​

 

1つはユーザのメールアドレスで。

OTPはそのメールアドレスに送信されて。

アカウントに正常にログインできるようになっていて。

 

さっそく、/login/signinリクエストをキャプチャして。

emailパラメータを既存より高い特権のユーザのメールアドレスに変更して。

攻撃者のメールアドレスに送信された正しい4桁のOTPを組み合わせて実行すると。

 {“ email ”:“admin@example.com”,“code”:<正しい4桁のOTP> } ​

 

アプリケーションの有効なユーザのアカウントにログインできて。

これは、メールとOTPの結合が緩いわけで。

 

Best regards, (^^ゞ

ひとりひとりの自覚をもった行動で、医療従事者と保健所職員を助けよう。

f:id:ThisIsOne:20200404115457p:plain