滥用 DHCP DNS 动态更新技术欺骗 DNS 记录

前言

对于攻击者来说，如何能欺骗 DNS 记录极具吸引力，因为这可能会造成破坏性的后果，包括敏感数据泄露、凭据泄露，甚至是远程代码执行。

在本博文中，我们将调查 DNS 中很少有人研究并由看似无害的 DHCP 功能所暴露出来的一个攻击面。通过使用它，我们发现了攻击者可用来欺骗 Microsoft DNS 服务器上的 DNS 记录的一些不同方法， 包括未经身份验证的任意 DNS 记录覆盖。

除了攻击流之外，我们还将详细介绍 Microsoft DHCP 服务器的内部工作原理、它与 DNS 和 Active Directory 的交互以及如何正确地保护这些接口。虽然网上有很多零散（且不准确！）的 DHCP 相关资源，但是我们相信本博文的内容才是有关该主题的准确、全面的资源。防御者只需认真阅读这篇博文，即可获得所有关键信息。

DNS 动态更新一个的重要功能是 安全更新，该功能旨在控制谁可以修改区域中的每条 DNS 记录。如果没有安全更新功能，DNS 服务器就会盲目地遵从所有更新请求的要求，从而让攻击者能够轻松地覆盖现有记录。有了此功能，默认情况下 DNS 服务器将仅接受对 ADI 区域执行安全更新（图 3）。

其他主体（一些拥有高级权限的内置组除外）不应拥有对该记录的相关权限。当其他主体尝试修改不属于它们或它们没有相关权限的 DNS 记录时，服务器会拒绝该更新。

攻击者可能对 ADIDNS 区域非常感兴趣。 NETSPI 的 Kevin Robertson 先前的研究 突出了一些针对这些 DNS 区域的令人感兴趣的攻击。我们想详细阐述此攻击面，因此开始深入研究其他相关功能，这让我们发现了一个有意思的功能，即 DHCP DNS 动态更新。

图 6 显示了 DHCP DNS 动态更新过程。

此功能很有用，但现在不常用（如上所述，大多数现代 Windows 客户端可以直接创建自己的记录）。尽管如此， Microsoft DHCP 服务器默认情况下已启用此功能，这意味着 DHCP 服务器将为发出 DNS 记录请求的任何客户端创建 DNS 记录。

请注意，DHCP DNS 动态更新 不需要由 DHCP 客户端进行身份验证 ，即网络中的任何人都可以从 DHCP 服务器租用一个 IP，因此从本质上来说，攻击者可以使用 DHCP 服务器代表他们自己对 DNS 服务器进行身份验证。 这让攻击者无需任何凭据即可访问 ADIDNS 区域。

Microsoft 似乎已注意到此功能带来的潜在风险，并确认了其中的一些风险，但攻击者和防御者中大多数人仍然对此攻击面一无所知

以下各部分将详细介绍可以通过滥用 DHCP DNS 动态更新实施的攻击。

1. 网络中的主机会尝试解析名称“PC.aka.test”并向 DNS 服务器发送查询。

2. “PC.aka.test”对于 DNS 服务器是未知的，因此后者会以“无此类名称”进行回应。

3. 然后，主机会发送 LLMNR 多播，以尝试在其 LAN 中找到“PC.aka.test”。

4. 攻击者会识别此尝试，然后请求从 DHCP 服务器租用一个 IP 并将“PC.aka.test”作为 FQDN。

5. 服务器会将动态更新请求发送到 DNS 服务器，并且将创建该记录。

现在，在网络中的任何主机下一次尝试解析“PC.aka.test”时，它们会被重定向到攻击者所在位置。攻击者现在要做的是触发 ntlmrelayx.py 并等待身份验证尝试。

此方法比标准 LLMNR/NBNS 欺骗方法和 ADIDNS 欺骗变化的效果更好。

• 典型 LLMNR/NBNS 欺骗不需要进行身份验证，但其受害者有限，都位于同一 LAN 中（因为 LLMNR/NBNS 是基于多播的）。

• ADIDNS 欺骗让我们能够以 LAN 外部的受害者为目标（因为 DNS 可以跨子网工作），但需要已经过身份验证的用户。

利用 DHCP DNS 动态更新，我们可以做到两全其美——攻击既能够作用于 LAN 外部的受害者，又不需要任何身份验证。

这真的非常棒，但我们能够做得更好。

覆盖现有记录

创建不存在的 DNS 记录很棒，但这让我们想起了另一个选项：如果我们尝试为已存在的主机名创建一条记录，会怎么样？我们能否以某种方法覆盖它们？理想情况下，这无法实现，对吧？但是…

我们发现了一些案例，在这些案例中未经身份验证的攻击者可以覆盖现有记录。我们将此技术称为 DHCP DNS 覆盖。在介绍这些案例之前，我们先来探讨一下有关 DHCP 动态更新过程的一些更多详细信息。

这些记录之间的关键区别在于它们的所有者。正如我们 在本博文先前部分中所述，在执行 DNS 更新时，系统会创建客户端记录，并将发送更新请求的主体指定为记录所有者。对于正常的 Windows 客户端，此主体为该客户端的机器帐户。

有人可能会猜想托管记录的所有者也是发出请求的客户端，但情况并非如此。当 DHCP 服务器代表客户端发送 DNS 更新时，它也会使用 自己的 机器帐户进行身份验证，而该帐户将成为记录所有者。

我们可以在图 12 中看到这一差别。PC2 是客户端所拥有的客户端记录，而 PC1 是 DHCP 服务器所拥有的托管记录。

总结如下：攻击者可以使用 DHCP 服务器发送任意 DNS 更新，但由于存在 ACL，DNS 记录应该不会被覆盖。

现在，我们了解了应该可以防止覆盖的机制，接下来我们将了解如何继续执行记录覆盖。

此记录的所有者是 DHCP 服务器机器帐户。现在，在租用过程中，我们通过攻击机器请求从 DHCP 服务器获取同一 FQDN。我们检查 DNS 区域，发现覆盖成功，现在记录指向刚才租给我们的 IP（图 17）。

此攻击没有问题，但其影响十分有限，因为它只影响托管记录。正如我们先前所提到的，这些记录远不如客户端记录更常用，而后者不会受到此攻击的影响。尽管如此，在某些情况下，客户端无法注册它们自己的记录，但我们仍然可以找到托管记录。这些客户端包括：

• 非 Windows 客户端

• 旧版 Windows 客户端

• 禁用客户端 DNS 更新的 Windows 客户端

此攻击更加可靠：如果 Microsoft DHCP 服务器存在于网络中，则可以保证获得匹配的客户端记录，而托管记录（先前的覆盖情境所需的）更加少见。

关于影响，攻击者将能够拦截发往 DHCP 服务器的任何通信。严重性取决于此流量的性质。在大多数情况下，拦截发往 DHCP 服务器的通信的能力可能会被滥用于拦截并中继凭据，或者捕获可能会安装在服务器上的其他服务的敏感流量。

说到敏感服务：如果 DHCP 服务器安装在网域控制器 (DC) 上，会怎么样？我们能否覆盖 DC 记录？嗯，事实证明我们可以做到。

我们的数据表明，在我们所观察到使用 Microsoft DHCP 服务器的网络中，这种存在风险的配置相当常见， 有 57% 的网络都将 DHCP 服务器安装在 DC 上。默认情况下，所有这些网域都容易受到攻击。

虽然 Microsoft 已在其文档中 确认了此风险，但我们认为，对这种错误配置的认识与其潜在影响不相符。

对 DHCP DNS 攻击的抵御措施以及攻击者如何能够绕过这些措施

上述所有攻击都适用于 Microsoft DHCP 服务器的默认配置。但是，有两种能够帮助抵御其中部分攻击的设置。我们来了解一下这些设置，以及攻击者如何绕过它们。

正如您所看到的，DHCID 记录值是以 Base64 编码的数据块。此值（我们稍后将在本博文中分析它）是一个独特的签名，旨在识别请求进行记录创建或更新的 DHCP 客户端。

当 DHCP 服务器收到修改 DNS 记录的请求时，它会计算客户端的 DHCID 值，并发送包含更新后的数据以及该 DHCID 值的 DNS 更新。

如果 DNS 服务器上尚不存在该记录，它会直接创建该记录和匹配的 DHCID 记录。但是，如果主机 (A) 和 DHCID 记录已存在，DNS 服务器会将现有的 DHCID 值与 DHCP 服务器发送的值进行比较。只有在两个值匹配的情况下，才会执行更新。

因此，从本质上来说，DHCID 记录用于将 DNS 记录与创建它的客户端相关联。在此关联创建后，只有此原始客户端才能修改该记录。

唯一标识符就是客户端的 MAC 地址。当收到来自客户端的释放消息时，DHCP 服务器会查找是否存在具有匹配地址和 ID 的现有条目，然后删除已存在的条目。如果启用了 DHCP DNS 动态更新，则除了释放 IP 地址之外，DHCP 服务器还会发送 DNS 动态更新，以删除客户端的关联 DNS 记录。

如果我们可以发送包含唯一 ID（MAC 地址）的 DHCP 释放消息，而该 ID 与目标的 ID 相匹配，则 DHCP 服务器会删除此记录，从而让我们能够为自己注册记录—— 要想绕过名称保护，唯一需要的便是受害者的 MAC 地址！ （请注意，无需更改我们的实际 MAC——此值将从 DHCP 标头中获取。）

如果我们与目标位于同一个 LAN 中，那么找到其 MAC 地址不费吹灰之力；例如，我们可以通过发送 ARP 请求来找到其 MAC 地址。但是，如果我们与目标不在同一个 LAN 中呢？我们有另一个选择。

暴力破解 DHCID 记录以绕过名称保护

DHCID 记录是在 RFC 4701中定义的，其算法相当简单：

1. 将以下值连接起来：

   • DHCP HTYPE（硬件类型）。对于以太网，此值为 01。

   • DHCP 客户端 ID 选项

   • 记录 FQDN（DNS 有线格式）

2. 对结果进行 SHA256 加密

3. 添加 DHCID 数据位（在 Windows 实施中，此值为常量）

4. 以 Base64 对结果进行编码

图 23 显示了一个 DHCID 计算示例。

所引用的代码 可用于根据指定的参数计算 DHCID 值。

这意味着，如果不存在匹配值，更新就会失败。由于客户端记录不应该具有 DHCID 记录，因此如果已启用名称保护，客户端记录就会免受 DHCP DNS 覆盖的影响，攻击者也就没办法绕过它。 应该如此。

这并不是名称保护功能的真正作用，更像是它的一个副作用，因为根据定义，名称保护仅用于保护托管记录。尽管如此，由于我们刚才所说明的逻辑，它也可以保护客户端记录。但是，即使是这种意料之外的防御措施，攻击者也可以绕过它们。

通过划分多个范围，可以更好地管理地址分配，还可以对不同的子网应用不同的策略。名称保护是可应用的策略之一，并且它是在范围级别上启用的，这意味着不同的范围可以具有不同的配置。

正如我们在本博文先前部分中所述，当我们尝试对客户端记录执行 DHCP DNS 覆盖时，我们会失败，因为地址租用来自 具有 名称保护的 DHCP 范围。但是，需要理解一件重要的事情：范围是一个 DHCP 术语。客户端记录不知道范围是什么，也未与任何范围相关联。

由于此原因，如果我们从已禁用名称保护的另一个范围租用了地址，则可以“绕过”此抵御措施。（如何从已禁用名称保护的另一个范围租用地址不在本博文的讨论范围内，但您可以查看 DHCP 中继选项）

这意味着，即使服务器上的单个范围已禁用名称保护，攻击者也能够覆盖客户端记录（考虑到先前讨论的错误配置之一）。

我们来回顾一下 DHCP 服务器安装在 DC 上的示例。在更新 DNS 记录时，使用的是 DC 机器帐户，该帐户拥有对区域中所有记录的相关权限。在配置了 DNS 凭据的情况下，可以改为使用一个弱帐户，这样攻击便不再有效。

配置 DNS 凭据很重要，因为它可以缩小 DHCP 服务器所暴露的攻击面。它应当能够抵御我们先前所介绍的极其严重的攻击。

但是，使用此功能时，您需要考虑两个细节：

• 所配置的凭据必须是一个弱用户。例如，如果我们将其配置为网域管理员，则 DHCP 服务器仍然能够覆盖任意记录。

• 由 DHCP 服务器创建的 DNS 记录的所有者仍然是同一凭据，并且仍然容易受到 DHCP DNS 覆盖的影响。

DNSUpdateProxy 组

在我们调查 Microsoft 的 DHCP 以及它与 DNS 的交互期间，我们发现了另一项可能被滥用的功能，即 DNSUpdateProxy 组。此组旨在解决托管记录的两个与权限相关的问题：客户端升级后的问题和多 DHCP 服务器问题。

第二个作用是“记录接管”功能，第一个修改由某个 DNSUpdateProxy 成员创建的记录的客户端会被授予该记录的所有权，并移除已经过身份验证的用户的写入权限。通过允许客户端在必要时修改并接管它们自己记录，这解决了客户端升级后的问题。

此问题仍然可以使用 DNSUpdateProxy 解决，因为此组具有一项附加功能。如果 DNSUpdateProxy 的某个成员尝试修改所有者是另一个成员的记录，则由于存在 ACL，更新将成功完成， 但这次 ACL 和所有权未发生更改。 这让多个服务器能够“共同拥有”记录。

安全风险和错误

到目前为止，您可能已了解 DNSUpdateProxy 组会带来安全风险：由此组中的成员创建的所有记录都可以被任何已经过身份验证的用户“窃取”。这不是漏洞，它只是对功能设计的滥用。Microsoft 已确认此风险。

除了此风险之外，我们还发现了另一个问题，该问题源自于似乎是 DNSUpdateProxy 功能实现中的错误。当此组中的成员创建 自己的 DNS 记录时，该记录会与同样容易受到影响的 ACL 一同创建，已经过身份验证的用户对其拥有写入权限。

图 31 显示了一个示例。我们的 DHCP 服务器 dhcp1.aka.test 记录最初拥有安全的 ACL。

我们看到网域用户现在拥有对新 DNS 记录的写入权限。这明显不是该功能的预期用途，由服务器创建的托管记录应该拥有经过修改的 ACL，但服务器自己的客户端记录不应该受到影响。

抵御 DHCP DNS 攻击

由很多与 DHCP DNS 动态更新相关的风险。我们来总结一下所有可能的不同服务器配置，并了解如何抵御先前介绍的攻击。

我们将谈到两种类型的记录，即由 DHCP 服务器创建的托管记录和由 Windows 客户端直接创建的客户端记录。

总结如下：

• 如果您不需要 DHCP DNS 动态更新，请将其禁用

• 如果您将弱用户配置为 DNS 凭据，则客户端记录应当是安全的

• 无论采用什么配置，都无法保护托管记录免受欺骗攻击；在可能的情况下，将静态 DNS 记录 用于敏感的非 Windows 主机

• 请勿使用 DNSUpdateProxy；改为在所有 DHCP 服务器中使用相同的 DNS 凭据

DNS 凭据

这是抵御针对客户端记录的 DHCP DNS 覆盖的最佳方法。使用高强度密码配置专用于此用途的弱用户。 如果您在 DC 上运行 DHCP 服务器，这一点至关重要。 此设置并非用于阻止对托管记录的 DHCP DNS 覆盖。

名称保护

从理论上来说，名称保护应该保护托管记录，但实际上攻击者可以很轻松地绕过它。但仍然应当启用此功能，以增加覆盖的难度。

虽然名称保护不适用于保护客户端记录，但如果对服务器的所有范围都启用了此功能，则仍然可以抵御覆盖攻击。

在 Microsoft DHCP 上配置名称保护时， 由两种方法来应用它：在服务器级别或在范围级别。有人可能认为，在服务器级别启用了名称保护就意味着在范围级别启用了名称保护，对吧？然而，事实并非如此。在服务器级别启用名称保护只能确保对服务器上创建的 新 范围启用该设置，但不会对现有的范围启用该设置。必须确认已在服务器上每个范围的范围级别上启用了名称保护。

DNSUpdateProxy

您不应该使用此组。它是一项安全风险，因为其成员创建的所有记录都容易被覆盖。

如果您有多个 DHCP 服务器并且希望它们一起工作，则应当改为使用 DNS 凭据。只需在所有 DHCP 服务器上配置相同的 DNS 凭据，这将允许它们相互编辑记录。

只有在您使用 Windows NT 4.0 客户端（或更低版本）并计划很快升级的情况下，DNSUpdateProxy 才有用。如果您有任何年代久远的客户端，那么您所面临的问题远比 DNSUpdateProxy 严重。

如果出于某种原因您必须使用 DNSUpdateProxy，我们建议您为每个组成员创建一条静态 DNS 记录。静态记录的所有者是其创建帐户，这应该不是不同服务器的机器帐户。这将阻止服务器创建它自己的具有不安全权限的记录。

DHCP DNS 欺骗

几乎没有方法可以阻止未经身份验证的攻击者创建不存在的 DNS 记录。唯一方法是在所有 DHCP 服务器上禁用 DHCP DNS 动态更新。通常，如果您的环境中不需要 DHCP DNS 动态更新功能，禁用此功能可能是个好主意。这将消除一些风险并帮助缩小攻击面。

总结

我们已将所有发现结果报告给 Microsoft，后者回应称上述所有问题要么是设计问题，要么未严重到实施修复的程度。

我们不太认同此说法。我们所强调的攻击影响可能非常严重——任由攻击者覆盖 DNS 记录而不进行任何身份验证，将使攻击者在网域中的主机上轻易获得“中间机”的位置。这很容易导致敏感信息和凭据泄露，还可以让攻击者实施中继攻击，从而入侵 AD 网域并升级特权。我们在本博文中分享的统计数据表明，对于很多数据中心网络来说此威胁是一个重大威胁。

由于 Microsoft 未计划修复这些问题，因此我们强烈建议防御者使用 Invoke-DHCPCheckup 来扫描自己的环境，尝试找到我们所强调的存在风险的配置。剧透告警——如果不更改默认配置，您很容易受到攻击。