eMudhra 1FA OTP ログインバイパス：公開RSAキーとレート制限の欠如がフローを壊した理由
バイパスの概要
Mastodonインスタンスcatgirl.cloudで@49016として投稿した研究者は、eMudhraがブラウザに配信するRSA公開キーを抽出し、それを使って自らのOTPリクエストを暗号化し、OTP検証エンドポイントをブルートフォースすることで、eMudhraの1FA OTPログインシステムの完全なバイパスを実証しました。投稿によると、デモ動画ではブルートフォースを高速化しておらず、攻撃者はCloudflare Turnstileを一度通過するだけでよいとされています。主張される結果は、OSINTでメールアドレスが見つかるeMudhra証明書保有者のアカウント乗っ取りです。
eMudhraのOTPフローの実際の動作
eMudhraのログインフローは、サーバーに送信する前にOTPペイロードをクライアント側でRSA公開キーに暗号化します。公開キーはブラウザに提供されるJavaScriptに埋め込まれているため、意味のある秘密ではありません。ログインページを読み込む誰でもそれを読むことができます。投稿はキーをそのまま公開しています：
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7/OR1az+yTKt1ZONkk+T
owML34smGCo8evpk4zLCsrc+LXtX20yERombX4xh2Sd3VDFML2LuOavB3PwGFfL0
Qr+gGPomq23nqaX9nr5SeSTpFbrxsEEVdipXXpucTFFhnzye7Y7ZodHNQSjUqQPu
L6ktk/YkP0B6k5lIMT//W/4gB3yU1UGCLcSvdMQJo5+I7OdIGxQbir4rtXpdm8qP
3pblFPJXcHc2urBHvJvatUpq/rY0Km4Cxz5ZJwM7MW/hxSRpiTXNoE58W8DHEQVq
ln7RDh0Cc7lA0Qvm92NJIohbi4KZzmq81UA2MyHwyxtkykQxRFO1gEU5i/dp/I5D
ZQIDAQAB
-----END PUBLIC KEY-----
公開された公開キーへのクライアント側暗号化は通常のパターンです。その目的は、リクエストボディを中間者（この場合はCloudflare）から不透明に保つことであり、クライアントを認証することではありません。Hacker Newsのコメンター、ignatellaが次のように述べています：
彼らは公開キーをjsに入れ、リクエストのボディを暗号化しています。これは、ユーザーの重要なデータがプロキシ（この場合はCloudflare）にアクセスされるのを防ぐための一般的なプラクティスであり、問題ありません。
実際のバグは検証エンドポイントであり、キーではない
脆弱性は公開キーが公開されていることではありません。脆弱性は、OTP検証エンドポイントが無制限の推測を受け入れているように見えることです。OTP空間が小さいため、自由にリクエストを送信できる攻撃者はそれを列挙できます。同じコメンターが失敗を正確に要約しています：
しかし、実際のバグは、OTPチェックに関連するエンドポイントにレート制限、無効化、または保護がないことであり、検索空間が限られているためブルートフォースが可能です。
Cloudflare Turnstileはそのエンドポイントの前にある唯一のゲートであり、投稿によると攻撃セッションごとに一度だけ解決する必要があります。Turnstileはボット検出レイヤーであり、認証制御ではないため、既に通過したクライアントが行うOTP推測の数を制限しません。
攻撃の速度
研究者は、デモ動画で示されたブルートフォースは高速化されておらず、「その速さ」と特徴付けています。投稿はまた、攻撃者はCloudflare Turnstileを一度だけ通過する必要があると述べています。ソース資料には具体的な1秒あたりのリクエスト数は記載されていないため、正確なスループットは投稿自体では確立されていません。
主張される影響：既存のeMudhra証明書の乗っ取り
投稿の最も深刻な主張は、バイパスが単一のアカウントに限定されないことです。著者は、「基本的に、関連するメールをOSINTで見つけてログインするだけで、既存のeMudhra証明書を奪うことができる」と書いています。つまり、攻撃チェーンは次のとおりです：オープンソースインテリジェンスを通じてターゲットのメールアドレスを見つけ、そのアカウントのOTPをトリガーし、コードをブルートフォースしてログインします。
Hacker Newsのコメンター、buildbotが当然のフォローアップ質問をしました：
つまり、誰かがあなたのメールを知っていれば、このCAを使用した人は誰でもアウトですか？
その質問はソース資料で決定的に答えられていません。投稿は能力を主張していますが、アカウントごとの成功率や確認された侵害のリストは公開していません。
ソースの注意点と未解決の詳細
議論のいくつかの詳細は、なめらかにするのではなくフラグを立てる価値があります：
- デモの数値の不一致。 コメンターhoherdが観察しました：「ツールが見つけた数字は1861でした。メールで送られたOTPコードは1858でした。何を見逃していますか？」ソースはこれを解決していないため、デモの正確な出力は完全に検証されたものとして扱うべきではありません。
- 説明のない以前のインシデント。 投稿は、「
4インシデント」の後でもeMudhraを信頼するかどうかを読者に問いかけて始まります。ソース資料はそのインシデントが何であったかを説明していません。 - 主張の範囲。 バイパスは1FA OTPログインパスについて説明されています。投稿は認証局の署名インフラストラクチャやRSA秘密キーの侵害を主張しておらず、「漏洩したCA証明書キー」とは明確に対比しています。
背景：CA市場におけるeMudhraの立場
Hacker Newsのコメンター、jttnrが別の議論にリンクし、「ああ、彼らがCAビジネスから撤退してよかった」と書きました。別のFLeXMurphyは、「セキュリティは彼らのビジネスの1%未満を占めている」とコメントしました。これらはコメンターの特徴付けであり、投稿自体の記述ではありませんが、なぜこの開示がそれほど衝撃的だったのかを説明しています。
このクラスのバグが繰り返し発生する理由
3つの設計上の決定がこの失敗モードを生み出し、それぞれ独立して回避可能です：
- 公開キーを信頼境界として扱う。 クライアントJavaScriptに含まれるキーへのリクエストボディの暗号化は、受動的な中間者から保護します。送信者を認証するものではなく、アクセス制御として決して依存してはなりません。
- サーバー側の試行制限のない短い数値OTP。 6桁または同様に小さいコード空間は、サーバーが失敗した試行に厳格な上限を課し、コードを迅速に失効させ、最初の使用後にコードを無効にする場合にのみ安全です。
- レート制限の代わりにボット対策を使用する。 CAPTCHAまたはTurnstileチャレンジは攻撃を開始するコストを上げます。攻撃を継続するコストは上げません。
OTPログインを実行する人への実用的な takeaways
- OTP検証をアカウント、IP、セッションごとにレート制限し、少数の失敗後にアカウントをロックするか再認証を要求します。
- OTPを積極的に失効させ、最初の成功した使用で無効にします。
- 公開されたキーへのクライアント側暗号化を、リクエストが正当である証拠として決して扱わないでください。
- CAPTCHAとTurnstileを自動化防止の摩擦として扱い、認証境界として扱わないでください。
- 検証試行のボリュームをログに記録し、アラートを発行します。これは、この攻撃を即座に表面化させたシグナルです。
コミュニティの反応
Hacker Newsのスレッド（155ポイント、46コメント）は、警戒とダークユーモアが混ざり合っていました。コメンターは、バイパスがeMudhraのインフラストラクチャ内の任意のアカウントへのログインを可能にするか（tommica）、CAのすべてのユーザーが露出しているか（buildbot）を尋ねました。他の人々はジョークに走りました — baal80spamは「eMudhraの『S』は『Secure』の略」と書き、cyberpunkは「インターネットを怒らせるな、結果が伴う」と雰囲気を要約しました。
別のコメントスレッドは脆弱性ではなくホスティングサイトに関するものでした。bragrとgilrainは両方とも、Mastodonインスタンスが無意味なテキストを配信したと報告し、gilrainはそれをアンチスクレイピングシステムに起因し、繰り返し訪問すると接続がリセットされると説明しました。これは書き込みの配信の問題であり、脆弱性に関する事実ではありません。