Hello there, ('ω')ノ
2FAバイパス Do Re Miを。
脆弱性：
2FA バイパス
記事：
https://medium.com/@ashlyn.lau_17206/2fa-bypass-do-re-mi-cfcfc3775d2e
すべての 2FA バイパス手法が同等に作られているわけではなく。
これまで遭遇した最も一般的なシナリオは、次のいずれかで。
・2FA チェックなしで保護されたエンドポイント
・サーバ応答での 2FA トークンの開示
今回は遭遇した新しいシナリオで。
認証のために有効なユーザ ID とパスワードを送信した後、アプリケーションは。
「ユーザだけが持っているもの」コンポーネントの ID の証明として。
第 2 要素認証を要求して。
任意のランダムな mtoken (123456 など) の値を入力し、[ログイン] を選択して。
予想どおり、入力された mtoken値が mtoken_secret値と比較して。
異なるハッシュ値を生成したため、2FA ログインは拒否され。
下記は、無効な mtokenを含むサーバの応答で。
開発者の直感では、目立った 3 つのパラメータ値があり見過ごされる可能性があって。
操作する 3 つのパラメータは次のとおりで。
Do: mtoken
Re: mtoken_secret
Mi: mtoken_t
これは、“”や 0 などのデフォルトの空または false 値から。
通常開始するロケット科学ではなく。
特定のフラグが false または値が null/空の場合、プログラムは。
2FA チェックをスキップし、値を変更して。
別の特徴的な組み合わせを作成することを想定していて。
Do Re Mi (試行1)
追跡を断ち切るために、下の最後のコンビが大当たりして。
サーバは、認証済みのセッション トークンを返して。
2FA 認証がバイパスされて。
Do: mtoken = 0
Re: mtoken_secret #最初のログイン サーバーの応答から返される値
Mi: mtoken_t = “”
Best regards, (^^ゞ
