2FA/MFA/OTP Bypass
Last updated
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
2FAをバイパスするには、パスを知っていることが重要で、次のエンドポイントに直接アクセスします。失敗した場合は、Referrerヘッダーを変更して2FA検証ページからのナビゲーションを模倣します。
アカウント内で以前に使用されたトークンを再利用することが効果的です。
自分のアカウントからトークンを抽出して、別のアカウントの2FAをバイパスすることを試みることができます。
ウェブアプリケーションからの応答にトークンが開示されているかどうかを調査します。
アカウント作成時に送信されるメール検証リンクを使用すると、2FAなしでプロファイルにアクセスできる場合があります。詳細は投稿で強調されています。
ユーザーのアカウントと被害者のアカウントの両方のセッションを開始し、ユーザーのアカウントの2FAを完了せずに、被害者のアカウントフローの次のステップにアクセスを試みることで、バックエンドのセッション管理の制限を悪用します。
パスワードリセット機能を調査し、同じリンクを使用して複数回リセットできる可能性があるかどうかを確認することが重要です。新しくリセットされた資格情報でログインすることで2FAをバイパスできるかもしれません。
信頼されたOAuthプラットフォーム（例：Google、Facebook）でユーザーのアカウントを妥協させることで、2FAをバイパスするルートを提供できます。
コードの試行回数に制限がないため、ブルートフォース攻撃が可能ですが、潜在的なサイレントレート制限を考慮する必要があります。
流れの制限が存在する場合でも、全体的なレート制限がない場合は、スローブルートフォース攻撃が可能です。
コードを再送信するとレート制限がリセットされ、ブルートフォース攻撃を継続できます。
クライアントサイドのレート制限をバイパスするための技術が文書化されています。
レート制限はログイン試行を保護するかもしれませんが、内部アカウントアクションには適用されない場合があります。
SMS経由でのコードの過剰な再送信は、会社にコストがかかりますが、2FAをバイパスするわけではありません。
単純なコードで無限のOTP生成が可能であり、小さなコードセットを再試行することでブルートフォースが可能です。
2FAバイパスのためのレースコンディションを悪用する方法は特定の文書に記載されています。
CSRFまたはクリックジャッキングの脆弱性を探求して2FAを無効にすることは有効な戦略です。
「ログイン状態を保持」クッキーの値を推測することで制限をバイパスできます。
X-Forwarded-Forヘッダーを通じて被害者のIPアドレスを偽装することで制限をバイパスできます。
サブドメインをテストすることで、2FAサポートがない古いバージョンや脆弱な2FA実装を使用している可能性があります。
/v*/ディレクトリパスで示される古いAPIバージョンは、2FAバイパスメソッドに対して脆弱である可能性があります。
2FAが有効化された際に既存のセッションを終了させることで、妥協されたセッションからの不正アクセスからアカウントを保護します。
2FAが有効化された際にバックアップコードが即座に生成され、特にCORSの誤設定/XSSの脆弱性がある場合に不正に取得される可能性があることはリスクです。
2FA検証ページでの機密情報の開示（例：電話番号）は懸念事項です。
アカウント作成、2FAの有効化、パスワードリセット、そしてその後の2FA要件なしでのログインを示すプロセスは、潜在的なバイパス方法を示しています。
デコイリクエストを利用してブルートフォース攻撃を隠蔽したり、レート制限メカニズムを誤解させたりすることは、バイパス戦略にさらなる層を追加します。このようなリクエストを作成するには、アプリケーションのセキュリティ対策とレート制限の挙動に対する微妙な理解が必要です。
OTPがユーザーが既に持っているデータに基づいて作成される場合、またはOTPを作成する前に送信される場合、ユーザーがそれを生成してバイパスすることが可能です。
P
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
