4 real? Tracking exploitation and patching of eMudhra’s weak keys

4 real？追踪对eMudhra弱密钥的利用及修复 | Cloudflare 博客

post

漏洞

密码学

事件响应

安全

2026年10月30日

4 real？追踪对eMudhra弱密钥的利用及修复

Maxime Guerreiro , Rupert Carr , Miguel de Moura , and Bas Westerbaan

8分钟阅读

复制链接

2026年10月19日，我们得知eMudhra拥有八个令人震惊的弱密钥：作为受信任的证书颁发机构，eMudhra本应为保护互联网的虚拟组合锁选择一个115位的数字，但他们却选择了数字4。甚至不是四位数，仅仅是数字4。其他七个密钥同样脆弱：56、66、115、155、156、230和237。

第二天，我们发布了一篇博客文章，说明我们立即采取的缓解措施，以及客户需要采取的行动以确保安全。现在，我们分享更深入的后续分析，包括我们观察到的利用证据，以及访客在修复系统方面取得的进展。

让我们从问题的规模开始。一个拥有如此严重弱密钥的证书颁发机构（CA）是前所未有的，潜在的后果也非常严重。虽然过去确实发生过许多证书颁发机构被入侵的事件（如DigiNotar、TÜRKTRUST和TrustWave），但这些事件中的密钥访问权限始终受到一定限制；这些事件仅限于特定攻击者或组织能够签发欺诈证书。而eMudhra事件本质上完全不同；受影响的中间私钥几乎可以被任何人从公开证书本身直接恢复。任何人都可以独立恢复这些签名密钥，并为任何未打补丁的客户端（未强制执行证书透明度）接受的域名创建证书。

eMudhra宣布他们将退出公共CA业务，并声称在密钥生成脚本中存在错误，但尚未公开该脚本。他们使用可能正确生成的密钥签署了一张证书吊销列表（CRL），随后又更正为使用弱密钥进行签名。

这种情况是如何发生的？为什么没有引发警报？许多问题需要澄清，包括审计师和交叉签名者的角色。这篇博客提出了组织应采取的修复措施和下一步行动，以确保自身安全。

Cloudflare的修复工作

我们最关心的问题仍然是Cloudflare、我们的客户以及整个互联网的安全影响。撰写本文时，所有高优先级的Cloudflare系统均已修复。目前正在处理少量确认的低影响工单。

我们于10月19日立即开始修复高影响系统。这些系统包括使用Pingora处理大部分出站连接的客户面向源的代理。这些系统在数小时内完成修复，以拒绝使用易受攻击的eMudhra密钥。同时，我们启动了基于AI的源代码分析，以找出所有信任这些弱密钥的其他系统。四小时内我们完成了全面分析。我们为每个系统分配了初步分析工单，并要求团队在当天结束前确认和/或调整分析结果。对于被识别为高影响的系统，我们要求立即修复；对于影响较低的系统，修复工作应在上周结束前完成。

Cloudflare是否观察到网络范围内的利用情况？

为了追踪客户服务器（或攻击者）使用eMudhra弱密钥签名证书的情况，我们在Pingora中增加了日志记录功能。由于该出站服务占Cloudflare机器发出的TLS连接的绝大多数，任何试图使用eMudhra密钥进行窃听的攻击者都会触发此日志记录。日志记录功能于10月21日完成部署。

在撰写本文时（一周后），我们观察到约22,000次使用弱eMudhra密钥的握手尝试。其中三分之二的尝试是访问测试站点（如emudhra.we-have-a-problem.com，我们在之前的开发指南中提到过该站点）。剩余三分之一的请求大多指向那些似乎使用弱中间证书为自己颁发证书的源站。由于我们已进行补丁修复，所有配置为验证证书的握手请求都被拒绝。

其中有约160次握手引起了我们的注意：证书的主题备用名称（SAN）指向其他组织的域名，与握手请求中的服务器名称指示（SNI）无关。其中一些域名与消费级物联网设备相关。我们还发现这些伪造证书是在密钥泄露后生成的，部分证书的有效期超过两年，这超过了任何公开CA的常规签发期限。但这些证书看起来更像是服务器自身的默认证书，而非用于拦截我们连接的伪造证书。它们命名的域名与实际连接的目标域名不同，因此即使不进行主机名验证也会失败。在多个案例中，服务器向我们多个地理位置的连接展示了相同的证书，这表明证书确实来自服务器本身，而非某个网络路径上的中间设备。

因此，到目前为止，尚无证据表明这些弱密钥被用于拦截Cloudflare的连接。但这些密钥似乎在漏洞公开后数小时内就被用于伪造证书：我们观察到的伪造证书中有一个时间为10月20日18:19 UTC，距离Mozilla公开漏洞报告不足一小时。这并不排除有针对性的拦截攻击可能性。对此，我们只能依赖系统被入侵的常规间接信号——截至目前，我们尚未发现任何此类信号。

仍有多少访客存在风险？

以上内容主要讨论了Cloudflare自身的修复措施，但我们的访客情况如何？我们无法在不中断连接的情况下直接测试访客是否仍然信任这些弱密钥，因此必须采用更间接的方法。为此，我们使用了挑战页面：

Cloudflare挑战页面示例

我们对部分挑战页面进行了更新，使其发送两个探测连接：一个连接到ca1.cloudflarecaptcha.com，另一个连接到ca2.cloudflarecaptcha.com。最初我们在ca1.cloudflarecaptcha.com上安装了eMudhra签名的证书，在ca2.cloudflarecaptcha.com上安装了常规签名的证书作为对照组。然后我们记录这些探测是否成功，从而判断收到挑战页面的访客是否仍然信任弱eMudhra密钥。

我们发现了什么？过去一周的5000万次探测显示：

重要前提：这些挑战页面的流量设计本身存在高度偏差。其中包含大量（未经证实的）机器人流量。此外，只有执行JavaScript的客户端（如浏览器）才会发送探测请求。

数据出现跳跃是由于以下变更（所有时间均为UTC）：

• 10月23日 15:30，我们更改了控制端点，使其也能提供eMudhra证书，但这次没有包含签名证书时间戳（SCTs）。接受情况存在一些差异，但影响不大。我们本可以新增一个端点，但这需要缓慢推出挑战平台的更新。更改现有端点更为简单。

• 10月23日 16:30，由于一个无关问题，我们的挑战平台回滚到之前的版本。探测器于10月27日10:00恢复运行。

• 10月27日 16:37，我们注意到未发送G3交叉签名，而并非所有客户端都知晓该签名，因此将其添加到两个端点。我们同时从两个端点移除了SCTs。

• 10月27日 16:49，我们将ca2链式连接到AAA证书服务根证书。

• 10月27日 18:18，我们逐步增加探测器覆盖范围，从非付费客户区域所有挑战页面的1%提升至10%。

撇开这些限制条件不谈：我们注意到什么？更新的现代浏览器大多已修复，但爬虫和旧版浏览器尚未修复。此外，嵌入式浏览器（如Android WebView）的修复进度滞后，仍有30-40%的接受率。在第一个周末（存在监控空白期），我们观察到明显的修复迹象，但之后几乎没有进展。

10月29日UTC时间18:00左右，我们发布了一个检测机制，捕捉到大量伪装成macOS上Chrome 150-154版本的爬虫流量。这在顶部图表中可能看起来像修复进展，但实际上这是流量分类方式的改变：相同的用户代理在底部图表中显示出检测到爬虫信号的流量接受率同步上升。

Linux系统上的Chrome 150-154版本是明显的例外：其接受率持续下降，与该群体进一步修复的趋势一致。鉴于爬虫流量占比高且变化频繁，这些证据更具提示性而非结论性。除此之外，我们仍观察到很少进展。

按网络（ASN）细分后我们发现：

在主要网络中，超过一半的探测器仍接受被破坏的证书链，这既包括未检测到爬虫信号的流量（顶部图表），也包括检测到爬虫信号的流量（底部图表）。周末期间我们观察到部分修复，但之后趋势趋于平稳。

主要警告依然有效：流量受到（尚未确认的）爬虫影响。但爬虫本质上也是需要安全更新的软件。如果它们在某种程度上能代表整体软件更新情况，那么当前形势确实令人担忧。

你能做什么？

进行修复！Dennis Jackson有一个很棒的众包网站，提供了详细的操作指南。特别是如果你是使用macOS的开发者，务必遵循这些指南。如果你是Cloudflare客户，请查看上周关于使用WARP或Tunnel等特定产品时需要在你端进行操作的博客文章。

未来展望

在Cloudflare，我们已在部分产品中部署了快速吊销机制。为了将该机制扩展到更多Cloudflare系统及行业，我们对像upki这样的项目感到兴奋，这些项目理解信任存储不能只是静态的根证书机构列表，而是需要能够快速更新吊销信息和证书透明度密钥等信息。随着漏洞被发现的速度比以往任何时候都快，快速而有效地处理这些漏洞变得至关重要。

目录列

讨论列

相关标签和社交媒体链接

相关标签

关注社交媒体

• Cloudflare

• Maxime Guerreiro

• Miguel de Moura

• Bas Westerbaan

电子邮件注册