Hello there, ('ω')ノ
フルアカウントの乗っ取りへのパスワードリセットの弱い暗号化を。
脆弱性:
アカウントの乗っ取り
パスワードのリセットの欠陥
暗号化の問題
記事:
ほとんどのアプリケーションは、電子メールを介して。
「パスワードをリセット」する機能をユーザに提供して。
今回は、パスワードリセットでの暗号化パターンの分析による。
アカウント乗っ取りの最近の発見ついて説明することに。
ターゲットをwww.target.comと呼ぶことに。
まずは、2つのテストアカウントに対してパスワード忘れを要求して。
<bugcrowd_alias>+1@bugcrowdninja.com
<bugcrowd_alias>+2@bugcrowdninja.com
この「+」がここでうまくいくことを知らない人のために。
「+」を電子メールに追加すると、電子メールのエイリアスが作成されて。
実際の電子メールで、すべての電子メールを受信して。
これは、ほとんどのアプリケーションがブロックせずに。
この結果が純粋に理解されたため、テスト中に非常に役立って。
実際のメールアドレス:
例:hbothra22@gmail.com
エイリアス:
例:hbothra22+1@gmail.com
例:hbothra22+harsh@gmail.com
上記のエイリアスの2つの電子メールは、実際の電子メールに転送されていて。
次にパスワードリセットフローには以下のとおりで。
新しいパスをリクエスト
⇩
一意のリセットリンクを受信
⇩
パスをリセット
ここで、リセットリンクを使用してパスワードをリセットしているときに。
これら2つのリセットリンクの違いは、1と2だけであることがわかって。
アカウント1のリンクをリセット:
https://target.com/reset_password?token=zbp.nwavaqjbeptho%401+neugboufenu
アカウント2のリンクをリセット:
https://target.com/reset_password?token=zbp.nwavaqjbeptho%402+neugboufenu
次に観察したのは、リセットトークンの長さは電子メールの文字数と同じで。
%40は、@がエンコードされたもので。
これで、アプリケーションに弱い暗号化メカニズムが。
導入されていることは確かで。
アプリケーションがトークンをどのようにエンコードしているかが。
まだ残っていたので、トークンが生成されていた式を導き出して。
Ceaser_Cipher_Key13(reverse(email)) ⇨ パスワードリセットトークン
まずは、被害者のメールアドレスを取得して。
例:hbothra22@gmail.com
メールを後ろから逆にすると。
例:moc.liamg@22arhtobh
次に、シーザー暗号を使用してリバースメールを暗号化して。
文字を右へ13シフトすると。
例:zbp.yvnzt@22neugbou
最後に@⇨%40に変更すると、リセットトークンが作成されて。
例:zbp.yvnzt%4022neugbou
これを使用して、任意のユーザのパスワードをリセットできて。
要点:
パスワードをテストするときは、常に2つのエイリアスを使用して。
リセットトークンのどのビットが異なるかを確認して。
Best regards, (^^ゞ