在组织的计算机网络中，Active Directory域控制器(DC)被视为最重要的核心资产之一。在DC中发现的漏洞通常比普通工作站中发现的漏洞更为严重。通过DC运行代码或提升用户权限的能力会严重影响网络安全态势；这将使攻击者能够完全控制该域下的所有代理和服务器。

2024年12月10日，由古河Yuki Chen(@guhe120)发现的一个影响所有DC的远程代码执行(RCE)漏洞作为最新"补丁星期二"更新的一部分在微软安全响应中心(MSRC)网站上公布。这个漏洞被标记为CVE-2024-49112，并获得了9.8分的CVSS评分。然而，目前还没有公开的漏洞利用程序或博文解释这个漏洞及其利用路径。

长话短说

SafeBreach Labs为CVE-2024-49112开发了一个概念验证漏洞利用程序，只要受害DC的DNS服务器具有互联网连接能力，就可以使任何未打补丁的Windows服务器（不仅仅是DC）崩溃，无需其他前提条件。

攻击流程：

1. 攻击者向受害服务器发送DCE/RPC请求
2. 受害者被触发向SafeBreachLabs.pro发送DNS SRV查询
3. 攻击者的DNS服务器响应攻击者的主机名和LDAP端口
4. 受害者发送广播NBNS请求以查找收到的主机名（攻击者的）的IP地址
5. 攻击者发送带有其IP地址的NBNS响应
6. 受害者成为LDAP客户端并向攻击者的机器发送CLDAP请求
7. 攻击者发送带有特定值的CLDAP引用响应数据包，导致LSASS崩溃并强制重启受害服务器

我们认为我们的发现具有重要意义，原因如下。首先，我们通过证明该漏洞可以用来使多个未打补丁的Windows服务器崩溃，展示了该漏洞的严重性。根据微软的分类，这个漏洞可以进一步被利用导致远程代码执行。其次，我们确认微软的补丁修复了整数溢出漏洞，该漏洞利用程序无法使打了补丁的服务器崩溃。最后，我们提供了一个公开的概念验证工具，组织可以用它来测试和验证其服务器是否受到保护。更多详细信息，请参见本文末尾提到的GitHub仓库。

技术深入分析

下面，我们将解释SafeBreach Labs研究团队如何识别触发漏洞并使DC（或任何Windows服务器）崩溃的利用路径的具体技术细节，提供逐步利用总结，并分享一个执行这些步骤的概念验证(PoC)工具。

CVE-2024-49112

CVE-2024-49112被命名为"Windows轻量级目录访问协议(LDAP)远程代码执行漏洞"。LDAP是微软Active Directory中工作站和服务器用来访问和维护目录服务信息的协议。漏洞的标题表明漏洞可能与LDAP相关代码有关。在MSRC的CVE页面上，微软提供了以下背景信息：

• "攻击者如何利用这个漏洞？

• 成功利用此漏洞的远程未经身份验证的攻击者将能够在LDAP服务的上下文中执行任意代码。但是利用的成功与所针对的组件有关。

• 在利用域控制器作为LDAP服务器的情况下，攻击者必须向目标发送特制的RPC调用以触发对攻击者域名的查找才能成功。

• 在利用LDAP客户端应用程序的情况下，攻击者必须说服或欺骗受害者对攻击者的域名进行域控制器查找或连接到恶意LDAP服务器才能成功。但是，未经身份验证的RPC调用将不会成功。

基于这些信息——并假设微软的文档准确——我们做出了以下假设：

1. 攻击者不需要进行身份验证
2. 漏洞是一个整数溢出类型，源自实现LDAP客户端逻辑的可执行文件或动态链接库(DLL)
3. 我们可以利用RPC调用来影响DC查询攻击者控制的LDAP服务器
4. 在DC的上下文中，漏洞可能存在于lsass.exe或它加载的DLL之一中，因为lsass.exe在DC上实现LDAP服务
5. 因此，具有易受攻击的LDAP客户端代码的RPC接口也位于lsass.exe或它加载的DLL之一中

此外，我们还在X上发现了Artur Marzano(@MacmodSec)的一个有趣见解，暗示微软对漏洞的补丁可能在wldap32.dll中：

这个见解与MSRC网站上的文档完全吻合，因为wldap32.dll实现了LDAP客户端的逻辑。

触发远程LDAP请求

我们首先证明了针对DC利用的第一步——影响它查询我们控制的LDAP服务器。我们需要找到一个源自lsass.exe本身或加载到lsass.exe中并从wldap32.dll导入函数的DLL中的RPC调用。使用RpcView，我们列出了加载到lsass.exe中的可用RPC接口：

在这些RPC接口中，我们只列出了那些来自依赖wldap32.dll并使用其导出函数的DLL的接口。我们在寻找不需要身份验证的RPC接口，因为我们假设攻击者不需要进行身份验证。我们发现了两个有趣的接口，它们提供了几个看起来与LDAP查询相关并可能触发查询的有趣命名的RPC调用，它们位于lsasrv.dll和netlogon.dll中：

使用IDA，我们自下而上搜索活跃使用从wldap32.dll导入的函数的RPC调用。经过长时间搜索，我们找到了DsrGetDcNameEx2。根据微软的文档：

"DsrGetDcNameEx2方法应该返回指定域和站点中域控制器(DC)的信息。如果AccountName参数不为NULL，并且在此方法调用期间有一个匹配所请求能力（如Flags参数中定义）的DC响应，那么该DC将已验证DC账户数据库中包含指定AccountName的账户。

NET_API_STATUS DsrGetDcNameEx2(

[in, unique, string] LOGONSRV_HANDLE ComputerName,

[in, unique, string] wchar_t* AccountName,

[in] ULONG AllowableAccountControlBits,

[in, unique, string] wchar_t* DomainName,

[in, unique] GUID* DomainGuid,

[in, unique, string] wchar_t* SiteName,

[in] ULONG Flags,

[out] PDOMAIN_CONTROLLER_INFOW* DomainControllerInfo

);"

这个函数看起来很有希望。它主动检索域控制器的主机名，并验证特定账户是否存在于其中。域名和账户都由调用者指定。这意味着如果该函数使用LDAP来完成其目的，我们就有了所需的东西。

接下来，我们需要理解DsrGetDcNameEx2的每个参数及我们将为它们设置的值：

• ComputerName：目标DC的主机名 – 这将设置为受害者的主机名（进一步研究发现这个值对函数完全没有影响）
• AccountName：将在查询的攻击者域中搜索的账户名称 —可以是任何名称—我们不关心它是否存在
• AllowableAccountControlBits：控制将查询关于"AccountName"的什么内容 – 可以是0 – 我们并不真正关心被查询的账户
• DomainName：将被查询的域 – 我们将其设置为攻击者的域名
• SiteName：DC必须位于的站点 – 可以设置为NULL
• Flags – 调用的额外配置 – 我们首先想要默认行为，所以设置为0
• DomainControllerInfo – 输出参数，返回的信息将放在这里

为了测试目的，我们在同一子网中安装了两个新的DC，并在每个DC中创建了两个新的根域。一个叫做SBRESEARCH.LAB，另一个叫做TESTDOMAIN.LAB。目标是在SBRESEARCH.LAB的DC上运行（攻击者），并让TESTDOMAIN.LAB的DC（受害者）查询SBRESEARCH.LAB的DC上的LDAP服务器。

因此在攻击者DC上运行时，我们在受害者DC上调用了DsrGetDcNameEx2函数。调用的参数是：

• ComputerName – WIN-ELD41******
• AccountName – blabla
• AllowableAccountControlBits – 0
• DomainName – SBRESEARCH.LAB
• SiteName – NULL
• Flags – 0

这还不够。在Wireshark中查看受害者发送和接收的数据包时，我们没有看到受害者发起任何LDAP请求。然而，Wireshark确实向我们展示了一些其他非常有趣的东西。我们看到受害者向其DNS服务器发送了关于SBRESEARCH.LAB子域的DNS查询。DNS查询收到了一个错误代码，说明DNS服务器没有找到关于该域的任何记录。然后这一切就说得通了。受害者DC获得这个查询的成功答复的唯一方法是如果攻击者DC是其DNS服务器。但我们不能就这样改变DC的DNS服务器；仅此一点就可能被视为一个漏洞：

发送的特定DNS查询是SRV类型。DNS SRV查询指定一个域名，在响应中映射到另一个域名和端口。受害者DC发送的两个查询的完整域名是：

• _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.SBRESEARCH.LAB
• _ldap._tcp.dc._msdcs.SBRESEARCH.LAB

看起来受害者DC确实在寻找我们攻击者域上的LDAP服务器。如果我们能让这个DNS查询成功解析，那么受害者可能就会发起LDAP查询。但如果我们不能改变受害者的DNS服务器，我们还能做什么？

我们是否必须控制受害者的DNS服务器才能让查询成功解析？受害者的DNS服务器不知道SBRESEARCH.LAB，但它知道其他域名。并非所有被受害者DNS服务器知道的域名都是手动配置的。这个DNS服务器当然知道"google.com"。谷歌是如何让这个DNS服务器知道它的？他们在互联网上购买了一个域名，所以我们也这样做了。

我们购买了域名"safebreachlabs.pro"来创建两个SRV记录：

• _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.safebreachlabs.pro
• _ldap._tcp.dc._msdcs.safebreachlabs.pro

这些SRV记录需要返回一个域名（不支持IP）和一个端口，受害者可能会将其作为LDAP服务器进行联系。乍看之下，这似乎意味着受害者必须联系一个在互联网上有公共IP的LDAP服务器，这是我们不希望有的要求，因为防火墙可能会阻止这种通信。但是，如果我们已经可以访问DC的子网，我们也许可以将SRV记录返回的域名设置为我们在子网中控制的计算机的主机名。因此，我们将这两个SRV记录映射到攻击者DC的主机名，以及端口389（其LDAP服务器）。

接着，我们进行了另一次测试。在攻击者DC上运行时，我们再次在受害者DC上调用DsrGetDcNameEx2函数，但这次将DomainName参数改为"safebreachlabs.pro"而不是"SBRESEARCH.LAB"，这次成功了。受害者DC向我们的攻击者DC发出了LDAP查询。

如上图所示，查询是以无连接LDAP（CLDAP）的形式发送的，使用UDP而不是TCP。使用Windbg，我们能够验证即使这个请求是通过CLDAP进行的，它仍然是由wldap32.dll执行的。

发送恶意LDAP响应

一旦我们成功让受害者DC查询我们的攻击者LDAP服务器，我们就可以继续研究该查询的响应中需要包含什么内容。这是为了让受害者执行Artur Marzano发现的假定易受攻击的函数 – LdapChaseReferral。

引用允许Active Directory树在多个LDAP服务器之间分区。当LDAP服务器无法回答请求时，它可以回复引用到其他可能提供查询答案的服务器。然后，客户端可以"追踪"这些引用并转而查询被引用的服务器。重要的是要注意客户端并不是必须"追踪"这些引用。然而，在我们的例子中它确实会追踪它们。

为了让服务器表明它没有查询的答案并将客户端引导到不同的服务器，它需要用"referral" LDAP结果代码（等于10）回复。响应还必须包含有效的LDAP URL（以"ldap://"或"ldaps://"开头）。

回到我们的利用场景，为了触发LdapChaseReferral函数，我们创建了自己的自定义LDAP UDP服务器，允许我们发送这样的引用响应数据包。

查看补丁的逻辑，微软添加了一个条件，验证某个值不大于另一个值。根据这个逻辑旁边打印的日志，这些比较的值被命名为"lm_referral"和"referral table size"。"lm_referral"取自"ldap_message"结构体（可能是我们的响应消息），而"referral table size"取自"ldap_connection"结构体。该条件检查"lm_referral"值是否在"referral table"范围内。这个范围就是"referral table size"。

在没有补丁的易受攻击版本中，这个"lm_referral"值确实被用来访问引用表内的某个偏移量：

在我们使用Windbg进行的测试中，我们看到"lm_referral"中的值总是等于0，而引用表的指针也等于0。但是，决定代码是否访问"referral table"的条件只验证"lm_referral"值是否不为零。这意味着为了触发漏洞，我们必须控制"lm_referral"变量并使其非零。如果我们成功了，那么代码将解引用一个我们可以用lm_referral的值控制的指针。

搜索"ldap_message"结构体中"lm_referral"变量被填充的位置，我们在wldap32.dll中查找使用"lm_referral"在"ldap_message"结构体中的偏移量(+0x3C)的其他位置。这导致了两个函数：LdapInitialDecodeMessage和LdapChaseReferral：

然后我们识别出在LdapInitialDecodeMessage中设置"lm_referral"的代码：

我们看到"msgid"和"lm_referral"是从数据包的同一部分获取的。在上面的截图中，由于向右移位25位，"value_from_response_packet"必须是一个4字节的DWORD，才能使"lm_referral"成为非零WORD。

在我们使用自定义UDP LDAP服务器发送的默认响应数据包中，我们可以完全控制"value_from_response_packet"的值（如上面截图所示），它是一个字节长。我们了解到这个值前面带有其长度。

然后我们明白了为了设置"lm_referral"的非零值需要做什么：

• 将表示"value_from_response_packet"（"lm_referral"和"lm_msgid"的组合）长度的字节从1改为4。
• 现在"value_from_response_packet"是4字节长，我们可以设置其最高有效字节，这将影响"lm_referral"。请记住，我们只能将这个字节设置为可以被2整除的值，否则我们会影响"lm_msgid"的值

这两个操作将代码流指向易受攻击代码的范围，并在解引用发生时创建一个访问违例：

由于"ref_table"等于NULL，而"lm_referral"此时是一个非零值，上图中最后一行代码将触发对一个不存在地址的解引用。

后续步骤

基于这里概述的初步研究，我们将继续努力实现完整的RCE链。为了不崩溃，并继续利用，我们计划找到一种方法为引用表分配一个非NULL值，同时为"lm_referral"设置一个值，使代码解引用这个表之外的地址。

我们已经创建了一个研究仓库，其中包含了LDAP Nightmare漏洞利用的概念验证，组织可以用它来测试和验证其服务器是否受到这个漏洞的保护。

受影响的Windows服务器

虽然我们的研究集中在测试Windows Server 2022（DC）和Windows server 2019（非DC），但我们相信这个利用路径和概念验证适用于补丁之前的任何Windows Server版本。

缓解措施

为了缓解这个漏洞的风险，组织应该实施微软发布的补丁，详细信息在这里(https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-49112)。如上所述，SafeBreach Labs验证了该补丁足以防止测试服务器被利用和崩溃。我们认为修补这个漏洞刻不容缓，但也理解修补DC和Windows服务器必须谨慎小心地进行。

因此，我们建议组织在可以应用补丁之前，实施检测来监控可疑的CLDAP引用响应（带有特定的恶意值）、可疑的DsrGetDcNameEx2调用和可疑的DNS SRV查询。

结论

这项研究旨在探索LDAP CVE-2024-49112漏洞是否可以被利用。我们的研究证明它不仅可以针对域控制器进行利用，还会影响任何未打补丁的Windows服务器。此外，我们提供了一个用于测试目的的漏洞利用概念验证，在上面的部分中已经提到。

致谢

我们还要感谢以下才华横溢的个人的工作：

• Yuki Chen (@guhe120) – CVE-2024-49112
• Artur Marzano (@MacmodSec)

关于我们的研究人员

• Or Yair (@oryair1999)
• Shahak Morag (@ShahakMo)

参考

• 博客原文：https://www.safebreach.com/blog/ldapnightmare-safebreach-labs-publishes-first-proof-of-concept-exploit-for-cve-2024-49112/

• github项目 exp地址：https://github.com/SafeBreach-Labs/CVE-2024-49112