shikata ga nai

Private? There is no such things.

An Account Takeover Vulnerability Due to Response Manipulationを訳してみた

Hello there, ('ω')ノ

 

応答操作によるアカウント乗っ取りの脆弱性を。

 

脆弱性:

 認証バイパス

 アカウント乗っ取り

 

記事:

 https://avanishpathak.medium.com/an-account-takeover-vulnerability-due-to-response-manipulation-e23fe629bd1

 

今回は、アカウント乗っ取りの脆弱性についての説明を。


まずは、アプリケーションに実装されているログイン機能についての簡単な説明から。

ユーザを認証するために、アプリケーションバックエンドは。

登録された電子メールIDに4桁のコードを送信して。

そのコードを入力した後に、アプリケーションはユーザの正当性を検証して。

有効なコードを持つ許可されたユーザのみがユーザのアカウントにアクセスできて。

 

f:id:ThisIsOne:20210820161610p:plain

 

攻撃シナリオ:

https://www.redacted.com/loginに移動すると、ログインフォームが表示されて。

上記のように有効な電子メールを入力すると。

4桁の認証コードがその電子メールアドレスに送信されて。

 

最初に被害者のメールアドレスを入力して。

4桁の認証コードをブルートフォース攻撃することを考えたものの。

アプリケーションには厳格なレート制限メカニズムがあって。

そして、10回の間違うとHTTP 429 Too Many Requestsの応答コードを返されて。

また、時間遅延などを試みても応答で認証コードがリークされなかったので。

成功しなくて。

 

なので、アプリケーションのポジティブログインフローを見てみることに。

テストアカウントの1つのメールIDを入力し、クリックした後に。

Burp Suiteを介してプロキシすることでポジティブログインフローを傍受すると。

予想通り、認証コードが上記の電子メールに送信されて。

この認証コードを入力すると、期待どおりにそのアカウントにログインできたので。

今度は、間違った認証コードを入力した後に何が起こるかを見てみると。

アプリケーションは、期待どおりに401 Unauthorizedエラーコードを返して。

 

f:id:ThisIsOne:20210820161534p:plain

 

ログイン機能をバイパスしようと何度も試みた後に注意を引いたのは。

{“ code”: ” invalid_credentials”}という応答本文のエラー応答で。

 

今度は、以前に成功した試行でキャプチャしたものに応答を置き換えて。

次にランダムな4桁のコードを入力して。

Burp Suiteでのログイン試行の応答をキャプチャして。

 

f:id:ThisIsOne:20210820161457p:plain

 

HTTP応答コードと応答本文を下記のように変更して、成功した試行に似せると。

アプリケーションとして実装されている認証機能をバイパスして。

そのアプリの任意のユーザ/管理者のアカウントにログインできて。

 

応答コード:

 HTTP/1.1 401Unauthorized ⇨ HTTP/1.1 200 OK

応答本文:

 {"code": "invalid_credentials"} ⇨ {"verify": "true"}

 

f:id:ThisIsOne:20210820161358p:plain

 

これは、受信した応答に基づいて。

後続のリクエストをトリガーするクライアント側のJavaScriptが。

認証されたユーザとして新しいセッションCookieを設定するために発生していて。

 

Best regards, (^^ゞ

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

f:id:ThisIsOne:20200404115457p:plain