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

概述

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

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

1. 对目标进行模糊测试直到你控制了指令指针。

2. 使用BFF 字符串最小化，找出哪些字节可用于存储你的 shellcode  。

3. 根据需要使用 ROP 来修改程序流，以便它执行你的 shellcode。

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

1. 软件发布方增强了模糊测试。

2. 软件及其运行平台上漏洞缓解措施的增多。

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

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

概念

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

• 已安装的服务

• 计划任务

我们如何在 Windows 系统上实现权限提升？只要特权进程与非特权用户可能影响的资源进行交互，就有可能出现权限提升漏洞。

寻找什么

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

1. 不存在的文件或目录。

2. 具有提升权限的进程。

3. 非特权用户可以写入的位置。

检查 1 和 2 可以在 Process Monitor 中轻松实现。检查 3 稍微复杂一些，如果我们将工具严格限制为 Process Monitor Filter 可以执行的操作，则可能会导致一些误报。但是我创建了一个过滤器[从 Github 下载]，它似乎可以很好地使特权升级漏洞变得非常明显。

使用过滤器

使用 Privesc.PMF 进程监视器过滤器相对简单：

1. 启用进程监视器启动日志（选项 → 启用启动日志）

2. 重启并登录

3. 运行进程监视器

4. 出现提示时保存启动日志

5. 导入“Privesc”过滤器（过滤器 → 组织过滤器 → 导入...）

6. 应用 Privesc 过滤器（过滤器 → 加载过滤器 → Privesc）

7. 查找并调查意外的文件访问。

调查结果

让我们首先查看一个我们作为漏洞分析师可能处理的常见基线的启动日志 - 安装了 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%20FilesVMwareVMware%20ToolsVMware%20VGAuthschemasxmldsig-core-schema.xsd。这是怎么发生的呢？如果包含空格的路径经过URL 编码，这些空格将被替换为 %20。

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

从非特权命令提示符中，让我们看看我们可以做什么：

成功！

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

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

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

POSIX 路径

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

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

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

使用从非预期路径加载的库

在某些情况下，开发人员可能没有做错任何事，只是使用了恰巧从可能受非特权 Windows 用户影响的位置加载的库。例如，以下是尝试访问路径C:CMUbinsasl2的应用程序的 Process Monitor 日志： 

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

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

作为非特权用户，我们可以创建目录并将任何代码放入其中。再次，我们让 calc.exe 以 SYSTEM 权限执行。所有操作均来自非特权用户帐户。

使用仅存在于开发人员系统中的路径

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

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

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

对正在使用的路径应用了意外的 ACL

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

与 Windows 软件相关的大多数 ACL 问题都与一个概念有关：从C:Program Files 或 C:Program Files (x86)

子目录执行的软件 默认 具有安全 ACL，  这是由于继承性。例如，假设我将软件安装到 C:Program FilesWD。非特权用户将无法修改 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 以确保其安全。只需将软件安装到推荐的程序位置即可避免这种不确定性。

测试并强化你自己的系统

您可以使用 Process Monitor 过滤器和上述技术来测试您自己的平台是否存在权限提升漏洞。对于任何被确定为不安全的文件位置，您可以手动锁定这些目录，以便非特权用户无法修改这些位置。对于您发现的任何漏洞，我们建议联系受影响的供应商，通知他们漏洞，以便为所有人修复漏洞。如果供应商沟通无效，CERT/CC 可能会提供帮助。