ZDI 打破障碍和假设 Windows 上的权限提升技术 part1

趋势科技ZDI计划中提交的链接跟随漏洞数量在过去几年迅速增加。这些提交让我们深入了解了这些漏洞是如何被发现和利用的。

在前几年，我们在这个漏洞类别中看到很多“低垂的果实”，只需在具有宽松DACL的目录中进行特权文件操作即可。而现在，如我们将在本博客系列中看到的漏洞，通常需要通过编程方式利用竞争条件。在之前的一篇博客中，我们分享了利用任意删除原语提升权限或通过任意文件或文件夹创建原语制造永久DoS状态的技巧。在本博客系列中，我们将讨论两种利用Windows遗留功能的技术，并通过我们发现的20多个漏洞提供各种示例。我们还将讨论尽管我们与多个供应商进行了努力和解释，但仍然未能解决的一些问题。这些技术是由Abdelhamid Naceri提交给ZDI的漏洞所衍生的。

什么是链接跟随漏洞？

链接跟随漏洞，亦称为CWE-59，发生在应用程序尝试通过文件名访问文件但未能正确阻止该文件名解析为非预期资源时。这意味着如果恶意用户创建了NTFS联结、硬链接或符号链接，易受攻击的应用程序将跟随该链接到系统上的不同位置。由于Windows中的默认行为是透明地跟随用户创建的链接，除非特别指示不跟随，大多数应用程序都会跟随这些链接。

侦察：何时、何地及如何

要寻找这种类型的漏洞，首先必须找到一个设计为以提升权限运行并执行各种文件操作的目标。在使用Procmon捕获文件操作日志后，首先需要确保文件操作发生在标准用户可访问的位置。

接下来，我们需要寻找创建、复制、移动、重命名或删除文件的文件操作。此外，对文件或文件夹的自主访问控制列表（DACL）的任何修改都可能值得关注。如果任何这些操作在未检查用户创建的链接的情况下发生，我们可能发现了可以利用的链接跟随漏洞！要成功利用链接跟随漏洞，首先必须熟悉可以用于创建链接的文件操作类型。可以在这里找到对不同类型有用文件操作的概述。

防御的视角

为了防止CreateFile操作跟随链接，我们观察到开发人员采用了几种策略。正如我们将看到的，并非所有这些都是合理的做法。

1. 使用FILE_FLAG_OPEN_REPARSE_POINT标志： 在打开文件句柄时，开发人员可以使用FILE_FLAG_OPEN_REPARSE_POINT标志。NTFS使用重解析点（reparse points），这是附加到文件或目录的一组用户定义的数据，以实现链接行为。此标志阻止默认的跟随重解析点行为，而是打开重解析点本身。因此，使用返回的句柄执行的任何后续操作将影响重解析点而不是其指向的文件。
2. 检查重解析标签： 开发人员可以在打开文件句柄后但在使用该句柄执行任何操作之前检查重解析标签。使用FileReparsePointInformation FileInformationClass值的NtQueryInformationFile函数可以检查文件或目录的重解析标签。如果开发人员实现了此功能，他们必须在每次打开新句柄时进行检查。
3. 使用受保护和隐藏文件： 另一种方法是在具有受限DACL的目录中包含受保护且有时是隐藏的文件。这将防止攻击者将目录变成挂载点，因为攻击者将需要提升权限才能删除受保护的文件。
4. 模拟： 我们观察到几种模拟实例，这允许在特定用户的安全上下文中执行文件操作。模拟用户的应用程序只能访问该用户可用的资源，即使是跟随链接。
5. 重定向防护： 最近引入的这种缓解措施在我们查看的目标中几乎总是被禁用。在本博客的未来更新中，我们将强调其使用情况以及我们能够绕过它的原因。有关重定向防护的更多详细信息，可以查看这个博客。

虽然此列表不是预防链接跟随漏洞的全面指南，但我们的研究确定了开发人员采用的这些安全措施，以使利用变得更具挑战性。

新缓解措施？

我们在开始研究时发现的一种看似有前途的技术，首次由James Forshaw在2015年讨论。这种技术源于应用程序不正确地使用模拟。这允许用户在其设备映射中创建一个符号链接，当应用程序模拟该用户并尝试打开驱动器上的位置时将会跟随该链接。例如，如果应用程序模拟当前用户并尝试打开C:Program Files，而用户在??C:创建了指向C:FakeRoot的符号链接，应用程序将打开C:FakeRootProgram Files。

我们再次从Abdelhamid Naceri那里了解到这种技术。这位研究人员指出，当以NT AUTHORITYSYSTEM身份运行的应用程序或驱动程序想要访问网络共享上的文件时，必须模拟映射该共享的用户才能这样做。这为我们提供了一个方便的工具来迫使我们感兴趣的产品使用模拟。如果应用程序未能撤销此模拟，通常发生在不可访问位置的文件操作可以被重定向到其他位置！然而，当我们开始尝试使用这种技术找到一些漏洞时，很快发现我们创建的符号链接并没有被跟随。

事实证明，2023年9月，微软发布了针对ZDI-CAN-21597和此漏洞类别中的其他报告的缓解措施。此缓解措施引入了未记录的函数ObpUseSystemDeviceMap，它将检查正在查找的文件是否在系统驱动器上。如果文件在系统驱动器上，并且正在使用模拟，那么将使用主令牌的设备映射而不是模拟用户的设备映射。这解释了为什么我们的符号链接没有被跟随，因为它们只存在于用户的设备映射中。

然而，这里有一个关键字可以潜在地被利用。此缓解措施仅适用于在系统驱动器上进行的文件查找，通常是“C:”。这意味着当文件操作发生在非系统驱动器上时，此技术仍然可以应用。在非系统驱动器上安装应用程序或通过某种方式触发系统驱动器之外的文件操作时，可以触发此类操作。在我们的研究中，这类操作很难找到，而且很少有产品允许您更改安装目录，但这种技术仍值得记住。

以下来自AVG和Avast的漏洞展示了链接跟随权限提升漏洞的失败检查。由于供应商未能与我们协调并发布补丁，因此这些案例的详细信息作为零日漏洞发布。在本博客的未来更新中，我们将提供来自另一个供应商的另一个有趣案例。请稍后查看该附录。

ZDI-CAN-22803和ZDI-CAN-22806：Avast免费杀毒软件和AVG免费杀毒软件链接跟随拒绝服务漏洞。

大多数防病毒解决方案允许用户将文件发送到隔离区并从隔离区恢复它们。隔离区通常是文件系统上的一个位置，潜在的恶意文件可以存储在其中，以免影响系统的其他部分。文件通常通过上下文菜单发送到隔离区，并可以通过UI永久删除或恢复。对于Avast Free Antivirus和AVG AntiVirus Free均是如此。尽管这两款产品由不同的供应商发布，但它们都属于同一母公司，并共享其大部分代码。示例来自Avast Free Antivirus，但所有描述的行为在这两个程序中都发生。

有趣的行为发生在从隔离区恢复文件时。首先，我们可以创建一个路径为“C:12TEST.exe”的文件，并使用Avast的UI将此文件发送到隔离区。文件被隔离后，我们有以下可用选项：

单击恢复，Avast将首先对文件的父目录进行一些检查，然后再重新创建它。此操作很有趣，但不是我们发现此漏洞的地方。我们开始问自己一个问题，如果文件的父目录不存在会发生什么？当我们在尝试恢复文件之前删除“C:12”时会发生什么？如果我们这样做并用Procmon记录文件操作日志，可以看到以下情况发生：

UI进程AvastUI.exe将首先检查文件是否已存在，然后检查文件的父目录是否存在。由于它们不存在，由Procmon中的PATH NOT FOUND指示，

AvastSvc.exe将被触发以重新创建不存在的目录。目录创建操作用蓝色突出显示，我们可以看到没有任何措施来防止链接跟随行为。未使用FILE_FLAG_OPEN_REPARSE_POINT标志，也没有在创建目录之前检查是否存在重解析点。此AvastSvc.exe进程还以NT AUTHORITYSYSTEM身份运行，这意味着我们可以滥用此行为来创建任意目录！

任意目录创建不会让我们做一些像提升权限那么酷的事情，至少在创建的目录没有宽松的DACL的情况下不会，但它可以让我们创建拒绝服务条件。如果我们在C:WindowsSystem32cng.sys创建目录，它将中断机器的启动过程，阻止其启动到Windows。我们可以通过在“C:1”创建指向我们希望新目录创建位置的联结来让AvastSvc.exe创建任意目录，在本例中为C:WindowsSystem32。而不是像上面那样命名子目录2，我们将其命名为cng.sys。这是利用此漏洞所需做的全部操作！在这种情况下，我们不需要担心赢得任何竞争条件。我们只需简单地创建一个联结。为了清晰起见，漏洞利用步骤如下：

1. 将路径为“C:1cng.sysTEST.exe”的文件隔离。
2. 删除路径“C:1cng.sys”。
3. 在“C:1”创建指向“C:WindowsSystem32”的联结。
4. 恢复已隔离的文件。

按照这些步骤，我们可以成功利用该漏洞：

第一个蓝色高亮事件显示AvastSvc.exe成功创建了目录C:WindowsSystem32cng.sys。第二个高亮事件显示在创建目录后进行的重解析点检查。虽然此检查会阻止我们的任意目录创建，但执行得太晚了。然而，这些和类似的检查确实阻止了我们将恢复的文件放置在可能提升权限的位置。

ZDI-CAN-22960 和 ZDI-CAN-22963: Avast Free Antivirus 和 AVG AntiVirus Free 链接跟随本地权限提升漏洞

在之前的案例中，我们跟踪了从隔离区恢复文件时的情况，其中必须重建整个文件路径。考虑另一种边缘情况：如果在重建路径的过程中被打断会发生什么？如果我们在 AvastSvc.exe 之前在路径中创建一个目录会怎么样？由于路径中的目录是使用 CREATE_NEW 处置创建的，因此如果目录创建失败，可能会有某种形式的错误处理。为了测试这种行为，我们可以再次隔离一个文件，比如 C:123TEST.exe，然后删除文件路径。然后，我们可以在尝试创建 C:123 目录的过程中恢复此文件。如果我们在 AvastSvc.exe 之前创建 C:123，我们会在 Procmon 中看到以下行为记录：

日志显示 AvastSvc.exe 成功重建了 C:1 和 C:12。我们的漏洞利用程序在 AvastSvc.exe 之前创建了 C:123，这导致 AvastSvc.exe 在尝试创建 C:123 时遇到名称冲突。这使得 AvastSvc.exe 表现出一些有趣的行为。AvastSvc.exe 会回头尝试删除它刚刚创建的每个目录。如果我们能滥用这种行为来删除一个任意目录而不是预期的目录，我们可以利用这一点来进行权限提升。再一次，当目录以删除访问权限打开时，没有任何措施可以防止跟随用户创建的链接。然而，问题出在之前发生的操作中：

在这些操作中，目录在被删除之前会进行检查。在此检查中，使用 FILE_FLAG_OPEN_REPARSE_POINT 标志打开目录的句柄，这在 Procmon 的处置信息中显示为打开重新分析点。接下来，服务调用 NtQueryInformationFile 来检索目录的 FileAttributeTagInformation，可以用它来确定目录或文件是否是重新分析点。如果此检查失败，意味着检查确定目录是重新分析点，则服务不会删除该目录，并且不会尝试删除任何其他目录。

然而，此检查容易受到检查时间与使用时间 (TOCTOU) 竞态条件的影响。由于检查和删除使用了不同的句柄，我们可以在检查之后但在删除之前尝试创建我们的链接。除了在 AvastSvc.exe 之前创建 C:123 外，我们还必须赢得这场比赛。除了反复隔离和恢复文件，别无他法，但这是可以接受的，因为没有什么能阻止我们重复进行直到赢得比赛。

还有另一个挑战需要解决。要在 C:12 创建我们的链接，必须清空该目录。这意味着除了在正确的时间创建链接以通过检查之外，我们还必须在创建链接之前删除 C:123。这需要在很短的时间内执行许多操作，因此我们应该做一些事情来提高成功的机会。

前几项内容涉及如何创建 C:123。使用 CreateFile 创建此目录时，我们可以将 CreationDisposition 值指定为 CREATE_NEW。这样可以让我们立即知道是否在 AvastSvc.exe 之前创建目录失败，因为如果 AvastSvc.exe 先创建了目录，则最后一个错误值将设置为 ERROR_ALREADY_EXISTS。这样我们可以立即停止并重试漏洞利用。创建 C:123 时可以做的另一件事是设置标志 FILE_FLAG_DELETE_ON_CLOSE。此标志使我们能够更快地删除 C:123，因为我们只需在创建时关闭打开的句柄。

通过改变我们使用的目录作为连接点，可以进一步给我们带来优势。我们将在 C:1 而不是 C:12 创建我们的连接点。这使得我们的漏洞利用程序有更多时间在 AvastSvc.exe 准备删除 C:1 之前完成所有操作。

最后的优化是我们可以使用单独的线程来创建连接点。线程在高优先级的紧密循环中反复尝试创建连接点，一旦 AvastSvc.exe 删除 C:12，连接点创建就会成功。此漏洞利用的步骤可以总结如下流程图：

实施这些步骤以及上述优化后，我们成功地使 AvastSvc.exe 跟随我们的链接并删除了目标目录：