使用进程监视器在 Windows 中查找权限提升漏洞

概述

这篇文章将解释如何在 Windows 上找到似乎没有人在寻找的提权漏洞，因为很容易找到一堆。在解释了如何找到它们之后，我将介绍一些可以以不同方式部分缓解问题的防御措施。但我希望看到的变化是开发人员开始以我描述的方式寻找这些漏洞，以便他们一开始就停止引入它们。

当我们第一次发布 CERT BFF时，针对内存损坏漏洞进行概念验证利用的通常过程是：

1. 对目标进行模糊测试，直到您控制了指令指针。
2. 使用BFF string minimization找出哪些字节可用于存储您的 shellcode  。
3. 根据需要使用 ROP 来修改程序流，以便它执行您的 shellcode。

使用 CERT BFF从 Start 到 PoC 通常相对简单 。随着时间的推移，利用内存损坏漏洞的门槛越来越高。这可能归因于多年来发生的两件事：

1. 发布软件的各方增加了模糊测试。
2. 在软件及其运行的平台中增加了漏洞利用缓解措施。

我最近研究了一种漏洞发现技术，这让我想起了早期的 BFF 日子。无论是发现漏洞的难易程度，还是利用漏洞的难易程度。事实上，这个概念是如此微不足道，以至于我对它在发现漏洞方面的成功程度感到惊讶。就像直接从使用 BFF 进行模糊测试到有效利用的想法随着时间的推移变得越来越不可行一样，我希望使用这种技术可以轻松找到更少的唾手可得的果实。

在这篇文章中，我将分享我的一些发现以及过滤器本身，用于使用 Sysinternals Process Monitor  (Procmon) 查找权限提升漏洞。

这个概念

在 Windows 平台上安装软件时，它的某些组件可能会以特权运行，而与当前登录系统的用户无关。这些特权组件通常采用两种形式：

1. 已安装的服务
2. 计划任务

我们如何在 Windows 系统上实现权限提升？每当特权进程与非特权用户可能影响的资源进行交互时，这就为特权升级漏洞打开了可能性。

要找什么

检查可能会受到非特权用户影响的特权进程的最简单方法是使用进程监视器过滤器，该过滤器根据以下属性显示操作：

1. 不存在的文件或目录。
2. 具有提升权限的进程。
3. 非特权用户可写的位置。

检查 1 和 2 可以在 Process Monitor 中轻松实现。检查 3 稍微复杂一些，如果我们将工具限制为严格限制使用 Process Monitor Filter 可以完成的工作，可能会导致一些误报。但是我创建了一个过滤器 ，它似乎在使权限提升漏洞非常明显方面做得很好。

使用过滤器

使用 Privesc.PMF Process Monitor 过滤器相对简单：

1. 启用进程监视器启动日志（选项 → 启用启动日志）
2. 重新启动并登录
3. 运行进程监视器
4. 出现提示时保存引导日志

1. 导入“Privesc”过滤器（过滤器→组织过滤器→导入...）
2. 应用 Privesc 过滤器（过滤器 → 加载过滤器 → Privesc）
3. 查找并调查意外的文件访问。

调查结果

让我们首先查看我们作为漏洞分析师可能会处理的常见基线的引导日志 - 安装了 VMware Tools 的 64 位 Windows 10 2004 系统：

即使我们的虚拟机中几乎没有安装任何软件，我们已经可以看到一些可疑的东西：  C:\Program%20Files\

Windows 用户可能熟悉路径 C:\Program Files\，但是 %20是什么？为什么会发生这样的文件操作？我们将在下面的部分中介绍原因。

开发者犯的错误

开发人员可能会犯许多错误，这些错误可能导致特权进程受到非特权用户的影响。我注意到的与 Windows 应用程序的简单权限提升漏洞有关的错误分为两大类：

1. 正在访问的意外路径。
2. 应用于正在使用的路径的意外访问控制列表 (ACL)。

正在访问的意外路径

在某些情况下，在程序执行期间会访问意外路径。也就是说，如果开发人员意识到正在访问该路径，他们可能会感到惊讶。这些意外的路径访问可能是由多种原因引起的：

URL 编码路径

正如我们在上面的屏幕截图中注意到的，VMware Tools 进程 VGAuthService.exe 尝试访问路径 C:\Program%20Files\VMware\VMware%20Tools\VMware%20VGAuth\schemas\xmldsig-core-schema.xsd。这怎么可能发生？如果包含空格的路径是URL 编码的，则这些空格将替换为 %20。

这种转变的后果是什么？这个新路径最重要的方面是 ，这个请求的路径现在开始查看根目录，而不是C:\Program Files\的子目录，默认情况下它具有适当的 ACL。Windows 系统上的非特权用户可以在系统根目录之外创建子目录。这将是一个反复出现的主题，所以请记住这一点。

在非特权命令提示符下，让我们看看我们能做什么：

成功！

我们可以通过选择文件访问并按 Ctrl-K 来获取调用堆栈，从而在 Process Explorer 中更深入地挖掘：

在这里我们可以看到文件访问是由 VGAuthService.exe + 0x110d9触发的，并且一路调用 xmlLoadExternalEntity()。

将所有部分放在一起，我们有一个特权进程，它尝试加载一个不存在的文件，因为路径是 URL 编码的。由于非特权用户可以创建此路径，因此现在变成非特权用户可以影响特权进程的情况。在这种特殊情况下，后果只是一个 XML 外部实体 (XXE) 漏洞。但我们也刚刚开始热身。

POSIX 路径

如果应用程序在 Windows 机器上使用 POSIX 样式路径，则该路径被规范化为 Windows 样式路径。例如，如果 Windows 应用程序尝试访问 /usr/local/ 目录，则路径将被解释为 C:\usr\local\ 。如上所述，这是非特权用户可以在 Windows 上创建的路径。

这是安装了完整补丁安全产品的系统的进程监视器日志：

使用一种通过 openssl.cnf实现代码执行的公知技术，我们现在可以通过从受限用户帐户以 SYSTEM 权限运行calc.exe来演示代码执行：

使用从意外路径加载的库

在某些情况下，开发人员可能没有做错任何事，只是使用的库恰好从可能受非特权 Windows 用户影响的位置加载。例如，这是一个尝试访问路径C:\CMU\bin\sasl2的应用程序的进程监视器日志：

如果我们查看调用堆栈，我们可以看到此访问很可能是由libsasl.dll库触发的：

果然，如果我们查看 libsasl 的代码，我们可以看到对路径C:\CMU\bin\sasl2的 硬编码引用 。

作为非特权用户，我们可以创建目录并在其中放置我们想要的任何代码。再一次，我们让 calc.exe 以 SYSTEM 权限执行。全部来自非特权用户帐户。

使用仅存在于开发者系统上的路径

有时，程序可能包含对仅存在于开发人员系统上的路径的引用。只要软件在没有此类目录的系统上正常运行，那么除非有人在查看，否则可能无法识别此属性。例如，此软件在 C:\Qt\ 目录中查找 plugins 子目录：

为简洁起见，我将跳过一些步骤，但经过一番调查，我们发现我们可以通过在适当的目录中放置一个特殊的库来实现代码执行：

进一步研究 Qt 开发平台，这种类型的漏洞是一个已知问题。该漏洞已在 5 年多前修复，但从未收到 CVE。如果软件是在引入此补丁之前使用 Qt 版本构建的，或者开发人员没有使用windeployqt修补存储在Qt5core.dll中的qt_prfxpath值，则该软件可能容易受到权限提升的影响。

应用到正在使用的路径的意外 ACL

大多数情况下，应用程序访问的意外路径都可以被利用，因为一个简单的事实：非特权用户可以在 Windows 系统根目录之外创建子目录。查找和利用未能正确设置 ACL 的软件只需要更多调查。

大多数与 Windows 软件相关的 ACL 问题都与一个概念有关： 从C:\Program Files\ 或 C:\Program Files (x86)\的子目录执行的软件 默认 通过继承 具有安全 ACL  。例如，考虑我将软件安装到 C:\Program Files\WD\ 的情况。非特权用户将无法修改 WD 子目录的内容，因为 非特权进程无法写入其父目录 C:\Program Files\，并且  默认情况下WD子目录将继承其父级权限。

使用 C:\ProgramData\ 目录而不显式设置 ACL

 无需提升权限即可写入ProgramData目录设计。 因此，默认情况下，在 ProgramData 目录中创建的任何子目录都可由非特权用户写入。根据 应用 程序使用其 ProgramData 子目录的方式，如果未显式设置子目录的 ACL，则权限提升可能是可能的。

这里我们有一个流行的应用程序，它有一个从 C:\ProgramData\ 目录运行的计划更新组件：

这是 DLL 劫持的一个简单的潜在案例，由于软件运行的目录上的 ACL 松懈，这成为可能。让我们在那里种植一个精心制作的 msi.dll，看看我们能完成什么：

这是我们的 calc.exe，以 SYSTEM 权限执行。这些问题似乎有点太普遍了。并且容易被利用。

值得注意的是，DLL 劫持并不是我们提升权限的唯一选择。 特权进程使用的任何 用户可写文件都可能引入特权提升漏洞。例如，这是一个流行的程序，它检查用户可创建的文本文件以指导其特权自动更新机制。正如我们在此处看到的，精心制作的文本文件的存在可能导致任意命令执行。在我们的例子中，我们让它启动 calc.exe：

安装到系统根目录下的子目录

默认情况下将应用程序放置到系统根目录之外的安装程序必须设置适当的 ACL 以保持安全。例如，Python 2.7 默认安装到 C:\python27\ ：

此目录的默认 ACL 允许非特权用户修改此目录的内容。我们可以用这个做什么？我们可以尝试标准的 DLL 劫持技术：

但我们甚至不需要那么聪明。我们可以简单地将C:\python27\目录中的任何文件替换为非特权用户：

允许用户指定安装目录而不设置 ACL

许多安装程序是安全的，因为从 C:\Program Files\ 继承了安全 ACL。但是，任何允许用户选择自己的安装目录的安装程序都必须在目标位置明确设置 ACL。遗憾的是，在我的测试中，我发现安装程序很少显式设置 ACL。我们来看看 Microsoft SQL Server 2019 安装程序，例如：

安装程序是否将 ACL 设置为安装软件的目录？

SQL Server 2019 启动时会发生什么？

Microsoft SQL Server 2019 以及几乎任何允许您选择安装位置的 Windows 应用程序，都可能仅根据安装到的目录而容易受到权限升级的影响。

对特权升级的防御

为非特权用户删除系统根目录上的“创建文件夹”权限

针对上述许多攻击的最简单防御方法是删除从系统根目录创建文件夹的权限：

不要在 C:\Program Files\ 之外安装软件

如果软件安装到 C:\Program Files\ 或 C:\Program Files (x86)\以外的任何位置，则您依赖安装程序显式设置 ACL 以确保其安全。您可以通过仅将软件安装到推荐的程序位置来避免需要做出这种信念的飞跃。