eMudhra 1FA OTP 登录绕过：公共 RSA 密钥和缺乏速率限制为何破坏了流程

一句话概括绕过

一位以 @49016 身份在 Mastodon 实例 catgirl.cloud 上发帖的研究者演示了完全绕过 eMudhra 1FA OTP 登录系统的方法：提取 eMudhra 随浏览器发布的 RSA 公钥，用它加密自己的 OTP 请求，然后对 OTP 验证端点进行暴力破解。帖子指出演示视频中的暴力破解并未加速，攻击者只需通过一次 Cloudflare Turnstile。声称的后果是：任何 eMudhra 证书持有者，只要其邮箱地址可通过 OSINT（开源情报）找到，账户就会被接管。

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 空间很小，能自由提交请求的攻击者可以枚举它。同一位评论者准确总结了失败原因：

但真正的 bug 是他们没有对 OTP 检查相关端点进行速率限制、失效处理或保护，因此它可以被暴力破解，因为搜索空间有限。

Cloudflare Turnstile 是该端点前唯一的屏障，而帖子声称每次攻击会话只需解决一次。Turnstile 是机器人检测层，而非授权控制，因此它不会限制已通过验证的客户端可以进行的 OTP 猜测次数。

攻击运行速度

研究者表示演示视频中展示的暴力破解并未加速，并称其“就那个速度”。帖子还指出攻击者只需通过一次 Cloudflare Turnstile。源材料中未给出具体的每秒请求数，因此帖子本身并未确定确切的吞吐量。

声称的影响：接管现有 eMudhra 证书

帖子中最严重的声称是绕过不限于单个账户。作者写道，你可以“基本上只要通过 OSINT 找到关联的邮箱然后登录，就能随便抢走任何现有的 emudhra 证书”。换句话说，攻击链是：通过开源情报找到目标的邮箱地址，为该账户触发 OTP，暴力破解验证码，然后登录。

Hacker News 评论者 buildbot 问了显而易见的后续问题：

所以基本上，如果有人知道你的邮箱，任何使用这个 CA 的人就完蛋了？

源材料中并未明确回答这个问题。帖子声明了这种能力，但没有发布每个账户的成功率或已确认被入侵的列表。

源中的注意事项和未解决细节

讨论中的几个细节值得指出，而不是忽略：

  • 演示中的数字不一致。 评论者 hoherd 观察到：“工具找到的数字是 1861。电子邮件发送的 OTP 码是 1858。我遗漏了什么？”源材料未解决这一点，因此演示的具体输出不应被视为完全核实。
  • 未解释的先前事件。 帖子开篇问读者在“4 事件”之后是否还信任 eMudhra。源材料没有描述该事件是什么。
  • 声称的范围。 绕过被描述为针对 1FA OTP 登录路径。帖子并未声称入侵证书颁发机构的签名基础设施或 RSA 私钥；它明确将该发现与“泄露的 CA 证书密钥”进行对比。

背景：eMudhra 在 CA 市场中的地位

Hacker News 评论者 jttnr 链接到另一个讨论并写道：“哦天哪，还好他们要退出 CA 业务了。”另一位 FLeXMurphy 评论说“安全业务占他们业务的不到 1%。”这些是评论者的描述，并非帖子本身的陈述，但它们说明了为什么该披露会引起如此大的反响。

这类 bug 为何反复出现

三个设计决策结合导致这种失败模式，且每一种都可以独立避免：

  1. 将公钥视为信任边界。 用随客户端 JavaScript 发布的密钥加密请求体只能防御被动中介。它不能验证发送者身份，绝不能作为访问控制依赖。
  2. 短数字 OTP 且无服务器端尝试限制。 六位数或类似的小代码空间只有在服务器强制严格限制失败尝试次数、快速过期代码并在首次使用后使其失效时才是安全的。
  3. 用机器人缓解措施代替速率限制。 CAPTCHA 或 Turnstile 挑战提高了发起攻击的成本。它不会提高继续攻击的成本。

给任何运行 OTP 登录者的实用建议

  • 对 OTP 验证按账户、IP 和会话进行速率限制，并在少量失败后锁定账户或要求重新认证。
  • 积极设置 OTP 过期时间，并在首次成功使用后使其失效。
  • 绝不要将客户端对已发布密钥的加密视为请求合法的证据。
  • 将 CAPTCHA 和 Turnstile 视为反自动化摩擦，而非授权边界。
  • 记录并告警验证尝试量，这是能立即暴露此类攻击的信号。

社区反应

Hacker News 讨论帖（155 分，46 条评论）将惊慌与黑色幽默混合。评论者询问该绕过是否允许登录 eMudhra 基础设施中的任何账户（tommica），以及 CA 的每个用户是否都暴露了（buildbot）。其他人则转向笑话——baal80spam 写道“‘eMudhra’ 中的 ‘S’ 代表 ‘Secure’” ——而 cyberpunk 总结了情绪：“别惹互联网，会有后果的。”

另一组评论关注的是托管站点而非漏洞。bragr 和 gilrain 都报告说被 Mastodon 实例提供了无意义的文本，gilrain 将其归因于反爬系统，并描述为在重复访问时重置连接。这是帖子交付问题，而非关于漏洞的事实。

Sources