DNS KeyTrap漏洞-针对DNSSEC校验的安全漏洞

2023年12月7日公开的CVE-2023-50387及相关的CVE-2023-50868，是针对DNSSEC的安全漏洞。

介绍

KeyTrap:互联网基础设施中的严重漏洞
研究人员发现了DNSSEC设计中的一个关键缺陷，即域名系统(DNS)的安全扩展(DNS安全扩展)，该扩展在所有DNS(域名系统)实现中引入了一个漏洞，供应商和服务提供商正在对其进行修复。
该漏洞可能会对DNSSEC校验和公共DNS提供商(如Google和Cloudflare)产生严重影响。在法兰克福歌德大学的Haya Schulmann教授的带领下，ATHENE团队开发了一种名为“KeyTrap”的新型攻击，展示了黑客如何利用设计缺陷:只需一个DNS数据包，黑客就可以瘫痪所有常见的DNS实现和公共DNS提供商。
这种攻击会对所有使用互联网的应用程序造成严重后果，包括网络浏览器、电子邮件和即时通讯等技术的不可用性。主要的DNS供应商称KeyTrap为“迄今为止发现的最严重的DNS攻击”。研究人员一直在与供应商和DNS提供商合作开发特定的补丁来关闭该漏洞。强烈建议所有DNS服务提供商立即应用这些补丁来缓解此严重漏洞。

DNSSEC简介

DNSSEC（Domain Name System Security Extensions，域名系统安全扩展）是一组用于增强DNS（Domain Name System，域名系统）安全性的扩展功能。它旨在解决DNS协议的安全性和信任问题，防止DNS查询遭到篡改和欺骗攻击。
DNSSEC仅指代RFC4033-4045中描述的，通过为资源记录添加签名为资源记录集提供身份验证的机制，与其他DNS安全相关措施无关。
DNSSEC通过不对称加密生成数字签名来提供数据验证，以确保DNS响应的完整性和真实性。主要包括以下几个方面：

1. 数据完整性： DNSSEC通过为DNS资源记录添加数字签名来确保数据的完整性。这意味着当客户端收到DNS响应时，它可以验证数据是否在传输过程中被篡改。

2. 身份验证： DNSSEC允许DNS服务器和域名所有者对其发布的数据进行数字签名，从而实现身份验证。这可以防止DNS欺骗攻击，确保客户端获取的DNS数据来自合法的来源。
   例如在如下请求中，DNSSEC校验器需要根据区域的DNSKEY来验证记录的RRSIG。
   
   

3. 链式信任： DNSSEC使用了一种称为“链式信任”的机制，通过在每个DNS区域中签名和验证资源记录，形成了一个信任链。这样，客户端可以跟踪信任链，从根域名服务器一直到最终的域名服务器，以验证DNS数据的真实性。

DNSSEC的部署可以有效地防止DNS劫持、DNS缓存投毒和DNS欺骗等攻击，提高了DNS的安全性和可信度。
DNSSEC的部署和使用有一些复杂性：

1. 配置复杂性： 部署 DNSSEC 需要在 DNS 服务器和域名注册商之间进行配置和交互。域名所有者需要生成密钥对、签名区域数据、更新 DS 记录等，这些过程需要一定的技术知识和经验。
2. 密钥管理： DNSSEC 使用了一系列的密钥对来实现数字签名和验证，包括 Zone Signing Key（ZSK）和 Key Signing Key（KSK）。密钥的生成、更新、存储和轮换都需要精心管理，以确保密钥的安全性和有效性。
3. 信任链管理： DNSSEC 信任链涉及到从根域名服务器到最终域名服务器的一系列数字签名验证过程。管理信任链需要确保每个区域都正确地签名和验证，以防止信任链中断或遭到攻击。
4. 性能影响： DNSSEC 的数字签名和验证过程可能会增加 DNS 查询的处理时间和带宽消耗，从而对 DNS 服务器和网络性能产生一定的影响。因此，在部署DNSSEC时需要权衡安全性和性能之间的关系。

国际上多数公共DNS解析服务提供商支持DNSSEC校验，如谷歌、cloudflare、威瑞信等公司提供的公共DNS服务。
（国内的公共DNS服务一般不支持DNSSEC校验）

受到攻击的现象和影响

攻击者在构造特定的DNSSEC签名的区域后，DNSSEC校验器在校验此类区域中的响应时，会造成极端的CPU消耗。
通过向目标解析器发送大量利用此漏洞的查询，攻击者可以严重降低解析器的性能，并造成DNS解析器无法为正常客户端实施DNS解析服务（DoS）。
在各DNS解析器修复版本发布前，需要关闭DNSSEC校验以避免此类攻击。

漏洞根因

详见ATHENE团队的技术报告，前因后果都介绍得很详细，看这个就够了：
https://www.athene-center.de/fileadmin/content/PDF/Keytrap_2401.pdf

为了尽可能地保证DNSSEC的可用性，从1999年发布的旧版DNSSEC协议RFC2535开始，就要求DNSSEC签名权威服务器发送所有的与请求相关的DNSSEC材料（密钥，签名等）；且要求DNSSEC校验器需要为所有的密文进行验证，直到验证成功。这一原则被新版本的DNSSEC协议延续（RFC4033-4035及后续更新）。
keytrap攻击基于以下几个要素：

• 密钥-标签冲突：
  在签名区域的密钥滚动和多算法支持期间，签名区域可以使用多个密钥。因此，在验证DNSSEC时，DNS解析器需要识别用于签名验证的合适加密密钥。DNSSEC使用密钥标记值来区分密钥，在每个签名中加入区域名称、算法、密钥标签的三元组，保证密钥签名匹配的效率。可以利用冲突的密钥标记导致解析器无法有效地识别合适的密钥，而必须使用所有可用的密钥执行验证，从而在签名验证期间增加计算工作量。
• 多密钥：
  DNSSEC规范规定解析器必须尝试所有冲突的密钥，直到找到一个成功验证签名的密钥或所有密钥都已尝试。这个要求是为了确保可用性。即使发生了密钥冲突(某些密钥可能导致验证失败)，解析器也必须尝试使用所有密钥进行验证，直到找到一个能够成功验证的密钥，从而确保签名的记录保持有效，从而确保相应的资源可用。然而，这种“积极验证”可能会导致验证解析器的大量计算工作，因为验证的数量随着碰撞键的数量线性增长。
• 多重签名：
  尝试所有可用的加密材料以确保验证的正确性的理念也适用于签名的验证。
  DNSSEC协议规定，在同一记录上有多个签名的情况下，解析器应该尝试所有签名。

漏洞修复方法

在DNSSEC协议更新前，ISC，NLnet Labs和AKAMAI实验尝试使用以下方法暂时缓解该漏洞：

• 限制失败次数：限制为0-32次。效果不佳，150qps仍会导致CPU停滞。
• 0失败容忍：无法缓解HashTrap，10qps就能导致72%的正常请求被丢弃。
• 限制密钥冲突：限制密钥标签冲突最多4个，不影响解析器的运行，且现行DNSSEC签名区域中，并没有使用超过2个冲突密钥的区域。但不能完全抵御SigJam攻击（使用单密钥和多签名）。
• 限制所有验证：密钥冲突限制为4次，密文失败限制为16次，ANY请求总验证次数限制为8次。但是在遭受攻击时仍会造成CPU负荷上升。

在unbound修复版本（完整修复代码见https://github.com/NLnetLabs/unbound/commit/882903f2fa800c4cb6f5e225b728e2887bb7b9ae）中加入了如下限制：

/** Max number of RRSIGs to validate at once, suspend query for later. */
#define MAX_VALIDATE_AT_ONCE 8
/** Max number of validation suspends allowed, error out otherwise. */
#define MAX_VALIDATION_SUSPENDS 16

并加入了签名校验的定时器，限制校验占用时间。

影响范围

所有执行DNSSEC校验的DNS解析器。

BIND9受影响版本

• 9.0.0 -> 9.16.46
• 9.18.0 -> 9.18.22
• 9.19.0 -> 9.19.20
  （由于CVE，ISC临时召回了部分发布的BIND9版本）

BIND9修复版本

ISC在2024.2发布了稳定版本9.16.48、9.18.24和开发版本9.19.21，修复这两个CVE：

• (CVE-2023-50387) 校验包含许多DNSSEC签名的DNS消息可能导致CPU负荷过重
• (CVE-2023-50868) NSEC3 closest encloser证明可能导致CPU负荷过重

unbound受影响版本

1.19.0及之前的所有版本

unbound修复版本

NLnet Labs在2024.2.13发布unbound 1.19.1版本，修复CVE：

• 修复CVE-2023-50387, DNSSEC验证复杂性可能会耗尽CPU资源并使DNS解析器停滞。
• 修复CVE-2023-50868, NSEC3closest encloser证明可能耗尽CPU。

参考链接

https://www.isc.org/bind/
https://kb.isc.org/docs/cve-2023-50387
https://nlnetlabs.nl/projects/unbound/download/#older-versions
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-50387
https://www.athene-center.de/en/keytrap
https://github.com/NLnetLabs/unbound
https://github.com/advisories/GHSA-8459-gg55-8qjj
https://www.athene-center.de/fileadmin/content/PDF/Keytrap_2401.pdf
https://github.com/NLnetLabs/unbound/commit/882903f2fa800c4cb6f5e225b728e2887bb7b9ae

杂谈

当初读DNSSEC协议的时候，就隐隐感觉到CPU时间占用的问题。为了有效性的各种算法和为了可靠性的各种穷举计算，有点烧CPU的味道。但是比起自己的直觉，我觉得DNSSEC协议开发者的大局观和现代芯片计算能力肯定要靠谱一万倍，没想到啊没想到。
刚看到BIND9和unbound都中招的时候，我还以为是某个加密算法的C库有bug之类的，结果keytrap漏洞利用的也不是什么密码学的高深漏洞，而只是DNSSEC本身的机制，严格遵循RFC的解析器都中招，所以漏洞的出现也是必然。
理论上几个DNS包就能干掉一个DNS解析器，但是实际实施起来应该还有些难度吧？毕竟都攻击DNSSEC了，除非设置了特殊的信任锚点，不然得完成到根域到攻击者区域的信任链条。也不知道当前能完成此类配置的区域有多少。如果存在提供信任链的恶意父级区域，放一个NTA应该也就都堵住了。
不过也有人在github上发布攻击这个漏洞的签名方案了，期待有人以此为契机，开发出更高级的攻击方式。
等DNSSEC协议更新不知道要等到啥时候，更新后会不会更复杂？拭目以待了。