DHCP 枚举
在我们之前的文章中,我们分享了 DHCP DNS 欺骗背后的理论。实际上,需要几条信息才能有效地执行我们描述的攻击。对于攻击者来说幸运的是,发现DHCP 服务器并了解其配置的能力是 DHCP 协议的一部分,这使得侦察过程变得微不足道。
在以下章节中,我们将描述攻击者可以从未经身份验证的环境中使用来收集这些不同信息的不同方法和技巧。
识别 DHCP 服务器
DHCP DNS 攻击中最重要的部分是目标 DHCP 服务器,因此第一步是识别一个 DHCP 服务器。识别网络中的活跃 DHCP 服务器非常简单。攻击者可以发送 DHCP Discover 广播并检查服务器的 Offer 响应。
要发送 DHCP 消息,我们可以运行dhclient Linux 实用程序 — 一个可配置的 DHCP 客户端,允许与 DHCP 服务器交互。我们可以通过编辑其配置文件来配置dhclient,该文件位于**/etc/dhcp/dhclient.conf**。
当我们运行它时,dhclient将从 DHCP 服务器请求网络配置并将其应用于我们的机器 - 覆盖我们当前的 IP 地址。为了避免这种情况,我们可以使用以下语法在虚拟接口上运行它:
dhclient <interface_name>:<virtual_interface_name>
复制
运行此命令后,我们可以看到我们的原始IP地址(172.25.14.55)保持不变,而我们的虚拟接口从DHCP服务器接收到了一个新的IP地址(图1)。如果我们记录流量并检查 DHCP Offer 消息,我们将能够识别所有活动的 DHCP 服务器(图 2)。
图 2:发送 DHCP Discover 来识别网络中的活动 DHCP 服务器
获取 DHCP 服务器的域和 DNS 服务器
在识别网络中的 DHCP 服务器后,我们需要知道哪些记录可以通过每个服务器进行伪造。DHCP 服务器只能在其关联的 ADI 区域内创建记录 - 与“aka.test”域关联的服务器只能写入具有相同后缀的 DNS 记录:*
此外,我们想知道哪个 DNS 服务器将托管新记录,这将使我们能够查询它们并验证攻击是否成功。
攻击者可以使用一种技巧来找出这两个参数,即参数请求列表选项,该选项允许查询 DHCP 服务器以获取特定设置。对于我们的目的,我们可以查询服务器关联的域名和域名服务器选项。
我们可以再次使用dhclient 。为了将参数请求列表选项添加到我们的发现消息中,我们在**dhclient的配置文件中包含以下行:
request domain-name, domain-name-servers;
复制
当我们运行dhclient(像以前一样,在虚拟接口上)并检查我们的发现消息时,我们看到它包含带有我们请求的字段的参数请求列表选项(图 3)。图 3:DHCP Discover 消息中的参数请求列表
监听的 Microsoft DHCP 服务器应向此 Discover 消息发送带有所请求参数的 Offer 响应(图 4)。图 4:DHCP 服务器响应我们请求的设置
推断名称保护状态
尝试滥用 DHCP DNS 动态更新时,另一个重要的设置是名称保护,因为此设置将决定某些覆盖攻击是否可行。我们无法直接查询名称保护的状态,但有一个简单的四步方法可以推断它。
-
使用 DHCP DNS 动态更新创建 DNS 记录 -
验证是否已创建 A 记录 -
向 DNS 服务器查询同名的 DHCID 记录 -
如果 DHCID 记录与 A 记录同时存在,则启用名称保护
要使用dhclient调用 DHCP DNS 动态更新,我们需要在配置文件中添加以下几行:
send fqdn.fqdn = “kali.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
复制
前两行添加了带有服务器标志的 FQDN 选项,这是使 DHCP 服务器为我们注册 DNS 记录所必需的。第三行是可选的,允许我们添加服务器标识符DHCP 选项,以便在存在多个 DHCP 服务器的情况下定位特定的 DHCP 服务器。
运行dhclient后,我们可以使用 nslookup 查询目标 DNS 服务器并查找 DHCID 记录(图 5)。图 5:使用 nslookup 验证名称保护状态
在这种情况下,我们可以看到已经创建了 DHCID 记录,这表明名称保护已启用。
推断 DHCP DNS 动态更新配置
有三个选项决定 DHCP 服务器在哪些情况下会为客户端创建 DNS 记录(图 6)。了解正在使用的设置可以让攻击者嗅探 DHCP 请求并识别导致创建托管记录的请求。这样,就可以识别托管记录覆盖的潜在目标(即欺骗 DHCP 服务器创建的记录)。
三种可能的设置是:
-
仅在客户端请求时动态更新。这是默认选项,仅当请求中存在 FQDN 选项且设置了服务器标志时才会创建 DNS 记录。 -
始终动态更新。无论服务器标志值如何,都会为任何具有 FQDN 选项的 DHCP 请求创建 DNS 记录。 -
动态更新不请求更新的客户端。即使没有 FQDN 选项,也会为客户端创建 DNS 记录 — FQDN 基于主机名 DHCP 选项。这旨在支持不使用 FQDN 选项的旧 DHCP 客户端。
图 6:DHCP DNS 动态更新设置
我们可以通过检查其“副作用”来推断此设置:我们将在不同条件下触发 DHCP DNS 动态更新,并查询 DNS 服务器以检查是否创建了记录。这可以通过使用dhclient租用 IP 地址并使用 nslookup 查询 DNS 服务器来完成。
测试每个可能设置所需的dhclient配置如下:
为未请求更新的客户端创建记录
# Only include the hostname option, without the FQDN option
send host-name = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
复制
始终创建记录(当存在 FQDN 选项时)
# Include the FQDN option, without the server update flag
send fqdn.fqdn = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
复制
仅当客户要求时才创建记录
# Include the FQDN option and the server update flag
send fqdn.fqdn = “test.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
复制
欺骗记录地址的限制
为了使攻击有效,我们需要伪造的 DNS 记录指向我们控制的机器。使用 DHCP DNS 欺骗,我们依靠 DHCP 服务器来创建这些 DNS 记录。不幸的是,我们不能选择任何任意的 IP 地址——DHCP 服务器具有定义的内部 IP 地址范围,并且它将拒绝租用(并随后为其创建 DNS 记录)此范围之外的任何 IP 地址。
因此,我们将通信重定向到的地址有两个限制:
-
该地址不能位于网络外部:我们无法从 DHCP 服务器租用外部 IP 地址,因此在欺骗时无法使用该地址。 -
该地址不能是具有静态 IP 地址的机器的地址:如果机器配置了静态 IP 地址,则该地址不太可能位于 DHCP 服务器的租用池中,因此不能用于欺骗。
因为我们可以访问可以使用动态 IP 地址的内部机器,所以我们可以使用 DHCP 服务器提供的任何地址作为我们的欺骗记录。
为了确保在执行其他操作时使用相同的地址,我们可以使用请求的 IP 地址选项。我们可以通过在**dhclient的配置中添加以下行来实现这一点:
send dhcp-requested-address 172.25.14.55;
复制
写入多个 DNS 记录
执行 DHCP DNS 欺骗时,我们很可能希望欺骗多个 DNS 记录,而不是单个记录,目的是重定向尽可能多的受害者的流量。但是,当我们尝试将多个 DNS 记录指向同一个目标 IP 时,我们遇到了一个问题。
DHCP 服务器将某个 IP 地址租借给主机后,其他客户端就不能再租用该 IP 地址。此行为旨在防止不同客户端之间发生 IP 冲突。当我们租用具有特定 FQDN 的 IP 地址来执行 DDSpoof 时,该 IP 地址将从服务器的地址池中删除。如果我们尝试再次租用具有不同 FQDN 的同一 IP 地址,服务器将提供不同的地址(图 7)。图 7:请求的地址已被占用时的 DHCP 租用流程 我们不能通过释放先前的租约来解决这个问题,因为这会触发 DHCP 服务器的 DNS 动态更新来删除刚刚发布的记录 — — 并会删除我们之前欺骗的记录(图 8)。
换句话说,我们的目标是:
释放 IP 地址;即从 DHCP 服务器中删除其租约条目并将其返回到地址池(以便我们可以使用它来注册新的 DNS 记录)
防止删除现有的欺骗性 DNS 记录
我们发现了一个有趣的行为/错误,使我们能够做到这一点。
我们向当前租用我们 IP 地址的 DHCP 服务器发送一个 DHCP 请求数据包,其中包含以下参数:
用于从服务器请求现有 DHCP 租约的客户端 MAC 地址
与我们的目标服务器不同的服务器标识符
看到此广播消息后,我们的目标 DHCP 服务器将“假定”我们正在从另一台服务器请求新的 IP 地址,因此我们不再需要现有的(租用的)IP 地址。然后它将删除 IP 租约,但不删除关联的 DNS 记录(图 9)。我们不清楚为什么 DNS 记录没有被删除;我们怀疑这可能是一个逻辑错误。图 9:删除租约条目而不删除其关联的 DNS 记录
让我们看看实际效果
我们希望创建两个指向同一 IP 的 DNS 记录。我们使用dhclient创建第一个记录,方法与前面所述相同。我们的记录已创建,如果我们查看 DHCP 服务器租约表,我们可以看到我们的租约就在那里(图 10)。图 10:DHCP 租约表条目
我们现在将配置文件中的dhcp-server-identifier dhclient选项修改为任何其他 IP,再次运行**dhclient,就会看到我们的租约被删除了!
我们现在只需使用不同的 FQDN 再次运行dhclient,同时请求相同的 IP 地址并创建第二条记录(图 11)。
DDSpoof.py 介绍 我们结合了本博客系列中描述的所有功能和技术,创建了 DDSpoof — 一个支持执行 DHCP DNS 攻击的工具包。此 Python 工具执行 DHCP 服务器枚举、执行自定义 DHCP DNS 命令并识别潜在的欺骗目标。DDSpoof 的功能记录在此存储库中。
在接下来的部分中,我们将研究可以使用 DDSpoof 执行的几种攻击场景。
设置DDSpoof 我们在目标网络内运行 Kali Linux 机器,没有任何域凭据。我们将首先运行 DDSpoof 来扫描网络并识别潜在目标(指定用于发送和接收数据包的接口;图 12)。图 12:DDSpoof 初始枚举 我们可以看到 DDSpoof 执行以下操作:
识别所有可访问的 DHCP 服务器及其配置
确定名称保护状态
验证我们当前的 IP 地址是否可以在目标服务器上租用
在这个例子中,我们的 IP 地址在目标服务器上无法出租,因此我们手动将其修改为服务器提供的 IP 地址(图 13)。图 13:将我们的 IP 地址修改为 DHCP 服务器上可用的地址
现在我们已经准备好开始进行欺骗了。
DHCP DNS 欺骗
要执行我们的第一次DHCP DNS 欺骗,我们需要识别失败的名称解析尝试,并为它们创建指向我们机器的 DNS 记录。为此,我们将使用 start-llmnr DDSpoof 命令。此命令启动 LLMNR 嗅探器,它将通知我们有关网络中的 LLMNR 查询,这可能会将我们引向潜在的欺骗目标(图 14)。图 14:使用 DDSpoof 的 LLMNR 嗅探器识别欺骗目标
这里我们可以看到嗅探器能够识别名称 files.aka.test。现在,我们可以使用 write-record 命令尝试注册此 DNS 名称(图 15)。图 15:使用 DDSpoof 欺骗目标名称的 DNS 记录
我们可以看到,DDSpoof 成功创建了此 DNS 记录,指向我们的 IP 地址!我们可以使用 nslookup 来验证这一点(图 16)。图 16:使用 nslookup 确认记录创建成功
下次网络中的主机尝试解析名称files.aka.test时,它们将被定向到我们控制的机器。
当我们完成攻击后,我们可以使用delete-record命令来删除我们的欺骗记录(图 17)。
图 17:使用 DDSpoof 删除我们的欺骗记录
DHCP DNS 覆盖
我们还有另一个选项,即 DHCP DNS 覆盖。如果我们回顾图 12,我们可以看到我们的目标 DHCP 服务器也是 DNS 服务器。这暗示该服务器也可能是域控制器 (DC),因为 DNS 服务器通常安装在 Active Directory 环境中的 DC 上。我们可以使用以下 nmap 命令来验证这一点:
Nmap -p389 -sV 172.25.14.123
图 18:Nmap 输出确认该服务器是域控制器
如果未配置 DNS 凭据,我们可以覆盖 ADI 区域中的任何记录。假设我们识别了一个名为 file-server.aka.test 的主机(图 19我们可以尝试使用write-record DDSpoof 命令覆盖其 DNS 记录。如果配置了弱 DNS 凭据,则此操作应该会失败。但是,在这种情况下,没有配置弱 DNS 凭据,因此我们的覆盖成功了(图 20)。
图 20:使用 DDSpoof 执行文件服务器 DNS 记录的 DHCP DNS 覆盖
图 21:使用 nslookup 确认覆盖成功### 绕过名称保护
在另一种情况下,我们运行start-dhcp DDSpoof 命令来嗅探 DHCP 流量,识别 DHCP 请求消息(图 22)。图 22:使用 DDSpoof 的 DHCP 嗅探器识别潜在的管理记录
在此示例中,我们识别了一台名为ubuntu-server.aka.test 的计算机,该计算机发送了包含其 FQDN 的 DHCP 请求。这可能导致 DHCP 服务器为其创建 DNS 记录,从而为托管记录覆盖提供机会(回想一下,托管记录是为非 Windows 主机创建的,因为它们不属于域,因此无法直接与 DNS 服务器通信)。
但是有一个问题,这次我们的目标DHCP服务器已经开启了名称保护功能(图23)。
图 23:DDSpoof 枚举启用了名称保护的 DHCP 服务器
如果我们查询目标ubuntu-server.aka.test的所有 DNS 记录,我们会发现确实存在 DHCID 记录(图 24)。
图 24:包含 DHCID 记录的 nslookup 输出
但无需害怕,因为我们已经知道,名称保护很容易被绕过!
为此,我们只需发送一个 DHCP Release,其中包含与原始记录所有者匹配的客户端 ID (CID)(本质上是客户端 MAC 地址)。这将导致 DHCP 服务器删除该记录。
为此,我们可以使用set-cid命令。我们为其提供之前获得的目标 CID,从而使 DDSpoof 模拟原始 DHCP 客户端。之后,我们可以运行delete-record命令来删除我们的目标记录(图 25)。
图 25:使用 DDSpoof 删除受 Name Protection 保护的 DNS 记录 现在,我们可以使用 write-record 命令简单地为自己注册名称(图 26)。
图 26:删除原始记录后使用 DDSpoof 创建新记录,绕过名称保护
概括
在本文中研究的攻击场景中,我们演示了如何从未经身份验证的上下文中伪造 Active Directory 域中的各种 DNS 记录。此功能非常灵活,攻击者可以通过多种方式滥用,包括:
-
瞄准 Windows 计算机并拦截 NTLM 或 Kerberos 身份验证,以便进行进一步的中继或暴力攻击 -
针对运行不安全协议并拦截敏感数据的应用程序 -
锁定内部安全服务器(如防病毒软件或 SIEM)的 DNS 记录,并阻止对它们的访问
这些只是威胁行为者滥用这种能力的几个例子;还有很多其他的例子。
原文始发于微信公众号(红云谈安全):DHCP DNS 欺骗武器化——实用指南
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论