目录导航
概述
这篇文章将解释如何在 Windows 上找到似乎没有人在寻找的特权升级漏洞，因为很容易找到一堆这样的漏洞。在解释了如何找到它们之后，我将介绍一些可以以不同方式部分缓解问题的防御措施。但是我希望看到的变化是开发人员开始按照我描述的方式寻找这些 vuls，以便他们首先停止引入它们。
回到我们第一次发布 CERT BFF 时，为内存损坏漏洞构建概念验证漏洞的通常过程是：
- 对目标进行模糊测试，直到您获得指令指针的控制权。
- 使用BFF string minimization找出哪些字节可用于存储您的 shellcode 。
- 根据需要使用 ROP来修改程序流程，以便它执行您的 shellcode。
使用 CERT BFF从Start 到 PoC通常相对简单 。随着时间的推移，利用内存损坏漏洞的门槛提高了。这可能归因于多年来发生的两件事：
- 发布软件的各方增加了模糊测试。
- 在软件及其运行的平台中增加漏洞利用缓解措施。
我最近在研究一种漏洞发现技术，这让我想起了早期的 BFF 时代。关于发现漏洞的难易程度以及利用它们的难易程度。事实上，这个概念是如此微不足道，以至于我对它在发现漏洞方面的成功程度感到惊讶。就像随着时间的推移，直接从使用 BFF 进行模糊测试到有效利用的想法变得越来越不可行，我希望使用这种技术可以轻松找到更少的容易实现的成果。
在这篇文章中，我将分享我的一些发现以及用于使用Sysinternals Process Monitor (Procmon)查找特权升级漏洞的过滤器本身 。
概念
当软件安装在 Windows 平台上时，它的某些组件可能会以特权运行，而不管当前哪个用户登录到系统。这些特权组件一般有两种形式：
- 已安装的服务
- 计划任务
我们如何在 Windows 系统上实现权限提升？任何时候特权进程与非特权用户可能能够影响的资源交互，这都为特权升级漏洞打开了可能性。
要找什么
检查可能受非特权用户影响的特权进程的最简单方法是使用进程监视器过滤器，该过滤器显示基于以下属性的操作：
- 不存在的文件或目录。
- 具有提升权限的进程。
- 可由非特权用户写入的位置。
检查 1 和 2 可以在 Process Monitor 中轻松实现。检查 3 稍微复杂一些，如果我们将工具严格限制在进程监视器过滤器可以完成的操作，则可能会导致一些误报。但是我创建了一个过滤器 ，它似乎在使特权升级漏洞变得非常明显方面做得很好。
使用过滤器
使用 Privesc.PMF Process Monitor 过滤器相对简单：
- 启用进程监视器引导日志（选项 → 启用引导日志）
- 重新启动并登录
- 运行进程监视器
- 出现提示时保存启动日志
- 导入“Privesc”过滤器（过滤器→组织过滤器→导入…）
- 应用 Privesc 过滤器（过滤器 → 负载过滤器 → Privesc）
- 查找并调查意外的文件访问。
调查结果
让我们首先查看我们作为漏洞分析师可能会处理的通用基线的启动日志 – 安装了 VMware Tools 的 64 位 Windows 10 2004 系统：
即使我们的虚拟机中几乎没有安装任何软件，我们已经可以看到一些可疑的东西： C:\Program%20Files\
Windows 用户可能熟悉路径 C:\Program Files\，但是 %20 是什么？为什么会发生这样的文件操作？我们将在下面的部分中介绍原因。
开发人员常犯的错误
开发人员可能会犯许多错误，这些错误可能会导致特权进程受到非特权用户的影响。我注意到的关于 Windows 应用程序的简单提权漏洞的错误分为两大类：
- 访问了意外的路径。
- 意外的访问控制列表 (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 以确保其安全。您只需将软件安装到推荐的程序位置，就可以避免这种信念的飞跃。
测试和强化您自己的系统
您可以使用上述 Process Monitor 过滤器和技术来测试您自己的平台是否存在提权漏洞。对于确定为不安全的任何文件位置，您可以手动锁定这些目录，以便非特权用户无法修改这些位置。对于您发现的任何漏洞，我们建议联系受影响的供应商将漏洞通知给他们，以便为每个人修复这些漏洞。如果供应商的沟通没有成效，CERT/CC 可能会提供帮助。