Hello there, ('ω')ノ
応答操作によるアカウント乗っ取りの脆弱性を。
脆弱性：
認証バイパス
アカウント乗っ取り
記事：
今回は、アカウント乗っ取りの脆弱性について説明することに。
アプリケーションに実装されているログイン機能についての簡単な説明：
ユーザを認証するために、アプリケーションバックエンドは。
登録された電子メールIDに４桁のコードを送信し。
そのコードを入力した後にのみ、アプリケーションはユーザの正当性を検証し。
有効なコードを持つ許可されたユーザのみがユーザのアカウントに。
アクセスできるようにして。
攻撃シナリオ：
https://www.redacted.com/loginに移動すると、ログインフォームが表示され。
上記のように有効な電子メールを入力すると。
４桁の認証コードがその電子メールアドレスに送信されて。
最初に頭に浮かんだのは、被害者のメールアドレスを入力して。
コードをブルートフォース攻撃を開始することでしたが。
アプリケーションには厳格なレート制限メカニズムがあり。
HTTP 429 Too ManyRequests HTTP応答コードが返されて。
１０回の間違った試行、および時間遅延などを導入する複数の設定を試行した後でも。
応答で認証コードがリークされなかったため、成功せず。
次に最初にアプリケーションのポジティブログインフローを見ることに。
そこで、テストアカウントの１つのメールIDを入力し。
ログインをクリックした後に。
Burp Suiteを介してプロキシすることでポジティブログインフローを傍受すると。
予想通り、認証コードが上記の電子メールに送信されて。
正しい認証コードを入力すると、そのアカウントにログインできたので。
そのリクエストをキャプチャして。
さらに調査するためにリピータへ。
間違った認証コードを入力した後に何が起こるかを見てみると。
アプリケーションは期待どおりに401 Unauthorized エラーコードを返して。
ログイン機能をバイパスしようと何度も試みた後、注意を引いたのは。
{“code”:”invalid_credentials”}という応答本文のエラー応答で。
ランダムな４桁のコードを入力し、Burp Suiteでのログイン試行の応答を。
以前に成功した応答をつかって操作してみることに。
応答コードHTTP/1.1 200 OKと応答本文{“verify”:”true”}にいくつかの変更を加えて。
成功したようにみせかけて。
HTTPコードをHTTP /1.1 401 Unauthorized ➡ HTTP /1.1 200 OKに変更し。
応答値を{“code”:”invalid_credentials”} ➡ {“verify”:”true”}に変更すると。
アプリケーションとして実装されている認証機能をバイパスし。
そのアプリケーションの任意のユーザ／管理者のアカウントにログインできて。
これは、受信した応答に基づいて後続のリクエストをトリガするクライアント側の。
JavaScriptがあり、認証されたユーザーとして。
新しいセッションCookieを設定したために発生していて。
Best regards, (^^ゞ
