Cloudflare 参与了一项涉及多供应商、覆盖全行业的工作，旨在缓解两个关键的 DNSSEC 漏洞。这些漏洞给提供 DNS 解析服务的关键基础设施带来了重大风险。Cloudflare 的公共解析器 1.1.1.1 服务免费为任何人提供 DNS 解析。在这些漏洞公开披露之前，我们已对 Cloudflare 的公共解析器 1.1.1.1 服务采取了缓解措施。在发布修复这些漏洞的新软件版本后，使用 unbound（开源软件）的内部解析器得到了及时升级。
在这两个漏洞披露之前，所有 Cloudflare DNS 基础设施都已受到保护，目前是安全的。这些漏洞不会影响我们的权威 DNS 或 DNS 防火墙产品。
所有主要的 DNS 软件供应商都发布了其软件的新版本。所有其他主要的 DNS 解析器提供商也都采取了适当的缓解措施。如果您尚未更新 DNS 解析器软件，请立即更新。
背景
域名系统 (DNS) 安全扩展（通常称为 DNSSEC）是 DNS 协议的扩展，它添加了身份验证和完整性功能。DNSSEC 使用密钥和签名来验证 DNS 响应的真实性。DNSSEC 协议规范具有某些要求，这些要求优先考虑可用性，但代价是增加了验证 DNS 解析器的复杂性和计算成本。本博客中讨论的漏洞缓解措施要求应用本地策略来放宽这些要求，以避免耗尽验证器的资源。
DNS 和 DNSSEC 协议的设计遵循稳健性原则：“做事要谨慎，接受他人的东西要宽容”。过去有许多漏洞利用了遵循此原则的协议要求。恶意行为者可以利用这些漏洞攻击 DNS 基础设施，在这种情况下，他们会通过制作具有复杂配置的 DNSSEC 响应来增加 DNS 解析器的工作量。通常情况下，我们必须在允许协议适应和发展的灵活性与维护我们所运营之服务的稳定性和安全性之间建立务实的平衡。
Cloudflare 的公共解析器 1.1.1.1 是一项以隐私为中心的公共解析器服务。我们一直在使用更严格的验证和限制，旨在保护我们自己的基础设施，以及保护在我们网络之外运营的权威 DNS 服务器。因此，我们经常收到有关解析失败的投诉。经验告诉我们，严格的验证和限制可能会在某些极端情况下影响可用性，尤其是在 DNS 域配置不当的情况下。但是，这些严格的验证和限制对于提高 DNS 基础设施的整体可靠性和弹性是必不可少的。
下文将介绍这些漏洞并说明我们如何缓解这些漏洞。
Keytrap 漏洞 (CVE-2023-50387)
简介
DNSSEC 签名区域可以包含多个密钥 (DNSKEY)，用于对 DNS 区域的内容进行签名，DNS 响应中的资源记录集 (RRSET) 可以有多个签名 (RRSIG)。需要多个密钥和签名来支持密钥轮换、算法轮换和多签名者 DNSSEC 等功能。DNSSEC 协议规范要求验证 DNS 解析器在验证 DNS 响应时尝试所有可能的密钥和签名组合。
在验证期间，解析器会查看每个签名的密钥标签，并尝试找到用于签名的关联密钥。密钥标签是一个无符号的 16 位数，它是密钥资源数据 (RDATA) 的校验和。密钥标签旨在允许将签名与据称创建该签名的密钥高效配对。但是，密钥标签不是唯一的，多个密钥可能具有相同的密钥标签。恶意行为者可以轻松制作 DNS 响应，其中包含多个具有相同密钥标签的密钥以及多个签名，但这些签名都无法通过验证。验证解析器在尝试验证此响应时必须尝试每种组合（密钥数量乘以签名数量）。这会使验证解析器的计算成本增加很多倍，从而降低所有用户的性能。这被称为 Keytrap 漏洞。
此漏洞的变体包括使用多个签名和一个密钥、使用一个签名和具有冲突密钥标签的多个密钥，以及使用多个密钥并将相应的哈希值添加到父委托签名者记录中。
缓解
我们已经限制了在区域切割时可以接受的最大密钥数量。区域切割是指父区域委托给子区域，例如 .com 区域将 cloudflare.com 委托给 Cloudflare 名称服务器。即使已经实施了此限制并为我们的平台构建了各种其他保护措施，我们仍然发现，处理来自权威 DNS 服务器的恶意 DNS 答案仍然需要耗费大量计算资源。
为了解决并进一步缓解此漏洞，我们为每个 RRSET 添加了签名验证限制，并为每个解析任务添加了总签名验证限制。一个解析任务可能包括对外部权威 DNS 服务器的多次递归查询，以回答单个 DNS 问题。超出这些限制的客户端查询将无法解析，并将收到带有扩展 DNS 错误 (EDE) 代码 0 的响应。此外，我们添加了指标，使我们能够检测试图利用此漏洞的攻击。
NSEC3 iteration and closest encloser proof 漏洞 (CVE-2023-50868)
简介
NSEC3 是用于验证拒绝存在的另一种方法。您可以在此处了解有关验证拒绝存在的更多信息。NSEC3 使用从 DNS 名称派生的哈希值（而不是直接使用 DNS 名称）来尝试防止区域枚举，并且该标准支持哈希计算的多次迭代。但是，由于完整的 DNS 名称用作哈希计算的输入，因此增加超出初始值的哈希迭代不会提供任何附加值，并且在 RFC9276 中不建议这样做。在查找 closest enclosure proof 时，这种复杂性会进一步加剧。来自权威 DNS 服务器的恶意 DNS 响应可以设置较高的 NSEC3 迭代次数和具有多个 DNS 标签的长 DNS 名称，从而通过使其执行不必要的哈希计算来耗尽验证解析器的计算资源。
缓解
对于此漏洞，我们采用了与 Keytrap 类似的缓解技术。我们为每个解析任务添加一个总哈希计算限制，以回答单个 DNS 问题。同样，超过此限制的客户端查询将无法解析，并将收到带有 EDE 代码 27 的响应。我们还添加了指标来跟踪哈希计算，以便尽早发现试图利用此漏洞的攻击。
时间表
UTC 日期和时间
|
Date and time in UTC |
Event |
|
2023-11-03 16:05 |
John Todd from Quad9 invites Cloudflare to participate in a joint task force to discuss a new DNS vulnerability. |
|
2023-11-07 14:30 |
A group of DNS vendors and service providers meet to discuss the vulnerability during IETF 118. Discussions and collaboration continues in a closed chat group hosted at DNS-OARC |
|
2023-12-08 20:20 |
Cloudflare public resolver 1.1.1.1 is fully patched to mitigate Keytrap vulnerability (CVE-2023-50387) |
|
2024-01-17 22:39 |
Cloudflare public resolver 1.1.1.1 is fully patched to mitigate NSEC3 iteration count and closest encloser vulnerability (CVE-2023-50868) |
|
2024-02-13 13:04 |
Unbound package is released |
|
2024-02-13 23:00 |
Cloudflare internal CDN resolver is fully patched to mitigate both CVE-2023-50387 and CVE-2023-50868 |
事件
2023-11-03 16:05
Quad9 的 John Todd 邀请 Cloudflare 参加联合工作组，讨论新的 DNS 漏洞
2023-11-07 14:30
一组 DNS 供应商和服务提供商在 IETF 118 期间开会讨论该漏洞。讨论和协作仍在 DNS-OARC 托管的封闭聊天组中进行
2023-12-08 20:20
Cloudflare 公共解析器 1.1.1.1 已完全修补，可缓解 Keytrap 漏洞 (CVE-2023-50387)
2024-01-17 22:39
Cloudflare 公共解析器 1.1.1.1 已完全修补，可缓解 NSEC3 iteration count and closest encloser 漏洞 (CVE-2023-50868)
2024-02-13 13:04
Unbound 包发布
2024-02-13 23:00
Cloudflare 内部 CDN 解析器已完全修补，可缓解 CVE-2023-50387 和 CVE-2023-50868
鸣谢
我们要感谢德国国家应用网络安全研究中心 ATHENE 的 Elias Heftrig、Haya Schulmann、Niklas Vogel 和 Michael Waidner 发现 Keytrap 漏洞并进行负责任的披露。
我们要感谢互联网系统联盟 (ISC) 的 Petr Špaček 发现 NSEC3 iteration and closest encloser proof 漏洞并进行负责任的披露。
我们要感谢 Quad9 的 John Todd 以及 DNS 操作分析和研究中心 (DNS-OARC) 促进各利益相关者之间的协调。
最后，我们要感谢代表各种 DNS 供应商和服务提供商的 DNS-OARC 社区成员，他们齐心协力，不懈努力地修复这些漏洞，朝着使互联网具有弹性和安全性的共同目标而努力。