“ Kerberos 中继曾经被认为是不可能的,但后来多位研究人员证明了事实并非如此。”
前言
基于 DNS 的 Kerberos
DNS在构建一个高效的Kerberos基础架构中扮演着不可或缺的角色。然而在 AD 环境中,DNS的功能远不止于此。
它还能够通过 Kerberos 实现经过身份验证的操作,这一功能主要体现在 “安全动态更新”(Secure Dynamic Update)机制中。
简单来说,安全动态更新的目的是确保那些使用动态IP地址的网络客户端能够自动将其当前的IP地址与DNS记录同步,从而避免因IP变化而导致的服务中断。
这一过程不仅提升了网络的灵活性,还通过Kerberos的身份验证机制增强了安全性,防止未经授权的客户端篡改DNS记录。下面一张图示详细展示了动态更新过程中涉及的各个步骤,了解这一机制的运作原理将有助于从根本上理解 DNS Kerberos Relay。
步骤从上到下,在此过程中,客户端是 Windows 10 ,服务器是具有 DNS 角色的 DC。
- 客户端查询 Start Of Authority (SOA) 记录以获取其名称,该名称指示哪个服务器对客户端所在的域具有权威性。
- 服务器使用授权的 DNS 服务器进行响应,在本例中为 DC
icorp-dc.internal.corp
。 - 客户端尝试对 A 记录进行动态更新,其名称位于区域
internal.corp
中。 - 服务器拒绝此动态更新,因为未提供身份验证。
- 客户端使用
TKEY
查询来协商经过身份验证的查询的密钥。 - 服务器使用
TKEY
资源记录进行应答,从而完成身份验证。 - 客户端再次发送动态更新,但现在附带
TSIG
记录,该记录是使用步骤 5 和 6 中建立的密钥的签名。 - 服务器确认动态更新。新的 DNS 记录现已就位。
这段查询包含了一个完整的 GSSAPI(通用安全服务应用程序接口)和 SPNEGO(简单且受保护的GSSAPI协商机制)结构,其中还嵌入了一个 Kerberos 的 AP-REQ(认证请求)。
这实际上是一个标准的 Kerberos 服务身份验证流程。服务器在回复时同样会返回一个 GSSAPI 和 SPNEGO 结构,用于确认认证成功,并通过 AP-REP(认证回复)进行响应。
这个 AP-REP 中包含了一个新的会话密钥,客户端可以利用该密钥对DNS查询进行签名,具体是通过 TSIG(事务签名)记录来实现的。
需要注意的是,encAPRepPart(AP-REP的加密部分)通常会使用只有客户端和服务器共享的会话密钥进行加密,因此正常情况下是无法直接解密的。
滥用 DNS 身份验证
如果我们能够成功拦截DNS查询,就有可能诱使受害者的客户端向我们发送真实DNS服务器的Kerberos票证。在默认的Windows配置中,同一(虚拟)局域网(VLAN)内的任何系统都可以利用 mitm6 工具来实现这种拦截。mitm6 会伪装成DNS服务器,这意味着受害者会将SOA(起始授权机构)查询发送到我们的虚假服务器。如果我们拒绝他们的动态更新请求,客户端就会尝试使用Kerberos进行身份验证。
但是实际并没有这么简单。通常情况下,DNS服务器角色会在域控制器(DC)上运行。因此,DNS服务的 Kerberos 票证已经适用于在DC上运行的其他服务,因为这些服务通常使用相同的账户。这意味着我们可以修改票证中的服务名称,从而将票证中继到其他服务,比如LDAP。
但是,如果我们仔细查看 TKEY 查询中的验证器,会发现请求完整性(签名)的标志已经被设置。这意味着即使我们能够拦截和中继票证,也无法绕过签名的验证机制,因为客户端和服务端会通过签名来确保数据的完整性和真实性。因此,尽管这种攻击在理论上是可行的,但在实际实施中会面临较大的技术挑战,尤其是在目标系统启用了严格的安全机制(如签名验证)的情况下。
这将自动触发 LDAP 签名,这会使整个攻击失败,因为如果不为每条消息提供有效的加密签名,我们之后就无法与 LDAP 交互。我们无法生成此签名,因为我们中继了身份验证,并且实际上并不拥有解密服务票证和提取会话密钥所需的 Kerberos 密钥。
幸运的是,我们可以站在巨人的肩膀上,Dirk-jan Mollema 已经帮我们解决了这些问题。
-
在 AD CS 的环境中,可以为受害者提供代码执行可能性。(https://dirkjanm.io/ntlm-relaying-to-ad-certificate-services/)
-
许多服务类实际上将隐式映射到 HOST 类,也包括 DNS。因此当受害者请求 DNS 服务的票证时,这实际上适用于具有 HOST SPN 的任何账户。默认情况下,这是在域中的所有计算机帐户上设置的,因此在这些帐户下运行的任何服务都可以作为目标。(https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html)
针对这两点,Dirk-jan Mollema 对 krbrelayx 和 mitm6 两个工具进行了优化。
最初 krbrelayx 并不是真正的中继工具,他更新了 krbrelayx 中的功能,使其能够在中继模式下运行,而不是在不受约束的委派模式下运行。krbrelayx 现在可用于中继 Kerberos 身份验证,但仅支持中继到 HTTP 和 LDAP。
对于 mitm6,他添加了指定中继目标的选项,当受害者询问查询 SOA 记录时,该目标将是权威名称服务器响应中的主机名。这将使受害者为我们所针对的服务而不是合法的 DNS 服务器请求 Kerberos 服务票证。
Kerberos Relay 攻击示例
首先,设置 krbrelayx,将 AD CS 主机(adscert.internal.corp
)指定为目标,并将接口的 IPv4 地址指定为要绑定 DNS 服务器的接口。这可以防止与通常在 Ubuntu 上侦听环回适配器的 DNS 服务器发生冲突。
sudo krbrelayx.py --target http://adscert.internal.corp/certsrv/ -ip 192.168.111.80 --victim icorp-w10.internal.corp --adcs --template Machine
接着,我们使用 AD CS 主机的名称作为中继目标来设置 mitm6:
sudo mitm6 --domain internal.corp --host-allowlist icorp-w10.internal.corp --relay adscert.internal.corp -v
等待受害者获得 IPv6 地址并连接到恶意服务器:
在流量中,我们可以看到预期的流程:
- 受害者 (
192.168.111.73
) 查询其主机名的 SOA 记录。 - 我们表明我们的恶意 DNS 服务器是权威名称服务器,受害者将向该服务器发送他们的动态更新查询。
- 查询被 mitm6 拒绝,这将向受害者表明他们需要验证他们的查询。
- 客户端与 KDC 通信,以获取我们指示的服务的 Kerberos 票证。
- 客户端与 krbrelayx 建立 TCP 连接,并发送包含 Kerberos 票证的 TKEY 查询。
- 票证将转发到 AD CS 主机,这会导致我们的身份验证成功并颁发证书。
icorp-w10
)python gettgtpkinit.py -pfx-base64 MIIRFQIBA..cut...lODSghScECP5hGFE3PXoz internal.corp/icorp-w10$ icorp-w10.ccache
列出 C$ 驱动器以证明拥有管理员访问权限:
防御措施
这种技术之所以能够成功,主要是因为它利用了 Windows 和 AD 中的一些不安全的默认配置,比如 Windows 对 IPv6 的偏好和 AD CS。防御这些问题可以采用以下几种方法:
1. 缓解 mitm6
mitm6 滥用了 Windows 即使在仅 IPv4 环境中也会查询 IPv6 地址的事实。如果不在内部使用 IPv6,则防止 mitm6 的最安全方法是通过组策略阻止 Windows 防火墙中的 DHCPv6 流量和传入路由器通告。完全禁用 IPv6 可能会产生不需要的副作用。将以下预定义规则设置为 Block 而不是 Allow 可防止攻击生效:
-
(入站)核心网络 - IPv6 动态主机配置协议 (DHCPV6-In) -
(入站)核心网络 - 路由器通告 (ICMPv6-In) -
(出站)核心网络 - IPv6 动态主机配置协议 (DHCPV6-Out)
2. 缓解中继到AD CS
默认 CertSrv
站点不使用 TLS,应先强制执行 TLS,然后才能启用进一步的保护。使用有效证书启用 TLS 后,在 IIS 中启用扩展保护以进行身份验证将防止中继攻击。应在提供此服务的所有单个 CA 服务器上的 AD CS 的所有基于 Web 的注册功能上启用此功能。
结尾
本文中提到的所有工具都已在 GitHub 上作为开源工具使用。公众号后台发送 krbrelay 获取工具链接。
想对该技术深入了解的师傅可阅读 Dirk-jan Mollema 的英文原文:(https://dirkjanm.io/relaying-kerberos-over-dns-with-krbrelayx-and-mitm6/)
中文转载请注明
原文始发于微信公众号(WH0sec):域渗透系列 - 通过 DNS 进行Kerberos Relay
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论