这些问题的根本原因来自常见的系统配置错误，这使得识别和利用这些问题非常可靠。相比之下，传统的基于内存损坏的本地权限提升漏洞通常需要固定偏移量，具体取决于目标使用的操作系统版本或系统构建。

可写系统路径目录漏洞

        可写路径本地权限提升漏洞源于系统管理员或应用程序安装程序修改系统路径环境变量以包含非特权用户可写目录的情况。

        此问题的典型根本原因是应用程序安装程序或管理员在适当目录（例如“程序文件”）之外安装应用程序，然后随后修改系统路径环境变量以指向已安装目录。结果，创建的目录从父目录继承了危险的权限。

        这方面的一个例子是在“C:\Program Files”目录中创建的目录与“C:\”目录中创建的目录的继承权限之间的明显差异。如下图所示，“Authenticated Users”组可以在“C:\”目录中创建文件和文件夹。此外，此权限是可继承的，这意味着它适用于所有未明确拒绝的已创建目录。

        相比之下，“Program Files”目录默认不包含此权限，“Program Files”中创建的文件夹默认阻止非特权用户写入，如下图所示。

        通过执行一个简单的实验，我们可以确认预期的行为。作为管理员，在 C:\Program Files\test 和 C:\test 中创建两个名为“test”的文件夹。接下来，创建一个非特权用户并尝试写入这两个目录。请注意，非管理员用户可以写入 C:\test\ 但不能写入 C:\Program Files\test\，如下图所示。

可写路径问题的利用

        用可写路径漏洞的最直接方法是识别以 NT AUTHORITY\SYSTEM 运行的应用程序服务，该服务尝试加载不存在的动态链接库 (DLL) 或尝试执行不存在的可执行文件。例如，服务可能会尝试加载仅存在于桌面操作系统上的 DLL 文件。由于该文件在服务器操作系统上不存在，它最终会遍历系统路径，寻找该文件。从操作的角度来看，攻击者的最佳方案是非特权用户可以触发此操作而无需重新启动目标系统。

        NetMan 服务，它允许非特权用户通过公开的 COM 接口 [1] 与其交互。一个重要的注意事项是，根据微软的说法，这种行为并不构成 Windows 中的漏洞，因为系统正在执行适当的操作来搜索路径 [3]。但是，如果第三方应用程序安装程序在安装过程中修改了系统路径环境变量并引入了可写路径权限问题，则这很可能符合应用程序安装程序中的漏洞/CVE。

        但是，从利用的角度来看，事情要复杂得多，因为易受攻击的服务可能会根据目标系统所利用的操作系统版本而有所不同。在下表中，我们概述了可用于通过 DLL 植入来提升权限的三个独立服务以及该技术可行的相应操作系统版本。

        当这些服务之一加载攻击者提供的 DLL 时，Windows 加载程序将调用 DllMain 函数，而不管目标服务调用了哪些导出的函数。执行 DllMain 后，攻击者可以将自己添加到本地管理员组中。虽然这对于概念验证漏洞利用通常很好，但从操作安全的角度来看，它通常并不理想。修改本地管理员的组成员身份可以创建事件日志条目，这些条目可以通过安全工具发出警报。一种更有效的方法是在特权服务上下文中执行远程管理工具，例如 Cobalt Strike 的信标有效负载。

        在某些情况下，尝试将信标加载到被劫持的进程中可能会导致死锁。操作员犯的一个常见错误是在 DllMain 中的被劫持进程的上下文中调用反射加载程序。因为 Windows 加载程序在 DllMain 执行期间持有加载程序锁，所以当反射加载程序还调用 LoadLibrary 并等待加载程序锁被释放时，从 DllMain 调用反射加载程序会导致进程死锁。解决此问题的最直接方法是等待服务调用与被劫持的 DLL 关联的导出，此时加载程序锁未激活。攻击者可以对相应的服务可执行文件执行逆向工程，以揭示受害服务利用了哪些导出。

使用 Windows 任务计划程序进行利用

        一种通过针对 Windows 任务计划程序服务来利用可写路径漏洞的方法。Gregory 发现此服务通过调用 LoadLibrary 函数在启动时尝试加载 WptsExtensions.dll 文件。利用此方法的缺点是触发目标服务的行为需要重新启动系统，因为该服务仅在系统启动时尝试加载 DLL。

        利用此向量的开发相对简单。攻击者只需将恶意 DLL 放入可写路径目录，然后等待或触发系统重启。但是，在 Windows Server 操作系统上，非管理用户无权执行关机或重新启动操作。此外，重新启动生产系统通常是不明智的，并且可能对红队的运营安全产生不利影响。

使用 NetMan 服务进行开发

        通过使用公开的 COM 接口枚举连接属性，Labro 可以触发对 LoadLibrary 的调用以加载“wlanapi.dll”文件 。虽然默认情况下任何支持的 Windows Server 操作系统上都不存在“wlanapi.dll”文件，但它确实存在于 Windows 10 上，这使得该技术仅在针对 Windows Server 执行权限提升时才可行。但是，即使在服务不能直接用于通过此向量进行本地特权升级的情况下，攻击者仍然可以使用该服务执行横向移动或建立持久性。

        在这种情况下，利用相对简单，只需将攻击者“wlanapi.dll”文件复制到可写路径目录即可。在 Windows Server 2012 R2 上，该服务将尝试加载名为“wlanhlp.dll” 的文件；但是，Praetorian 的测试表明该服务现在尝试加载“wlanapi.dll”。接下来，攻击者需要利用 Labro 提供的代码来枚举 COM 上的网络适配器，从而触发 DLL 加载尝试 。

IKEEXT 服务的奇特案例

        在一篇题为“分类 DLL 植入漏洞”的文章中，Microsoft 安全响应中心 (MSRC) 团队描述了他们在分类各种类型的 DLL 植入问题时遵循的流程。MSRC 声明“属于 PATH 目录 DLL 种植类别的 DLL 种植问题被视为‘无法修复’。” [3] 在 IKEEXT 服务的案例中，Microsoft 似乎偏离了这一既定政策的一个有趣案例。

        在这种情况下，微软似乎已经通过修改 LoadLibrary 调用来解决 IKEEXT 服务 DLL 劫持问题，改为调用 LoadLibraryEx，并将 LOAD_LIBRARY_SEARCH_SYSTEM32 标志设置为仅在 System32 目录中搜索“wlbsctrl.dll”文件。

        但是，由于该服务在启动时仍尝试加载不存在的 DLL，因此该服务对于利用任意写入问题或执行横向移动仍然有用。

替代开发技术

        之前我们说过，利用可写路径漏洞最简单的方法是识别以“NT AUTHORITY\SYSTEM”运行的服务，该服务试图通过遍历系统路径来加载不存在的DLL。但是，确实存在另一种方法来利用此问题，方法是执行相同的攻击，但针对以“NT AUTHORITY\NETWORK SERVICE”或“NT AUTHORITY\LOCAL SERVICE”运行的服务。默认情况下，Windows 服务被赋予 SeImpersonatePrivilege 权限。

        其中记录了他们发现 Windows 传真服务在启动时尝试加载不存在的 DLL。此外，Windows 传真服务的配置使得任何用户都可以触发服务的启动。

        因为默认情况下 Windows 传真服务被授予 SeImpersonatePrivilege 权限，所以可以首先创建一个命名管道，然后诱导更多特权服务访问命名管道以模拟客户端服务。在这篇文章中，作者利用了 James Foreshaw 在他的帖子“Sharing a Logon Session a Little Too Much”中记录的一种技术。该技术涉及创建命名管道并使用 \\localhost\ 路径通过它进行连接，这会触发来自 SMB 网络重定向器的身份验证。

        然后，作者利用模拟来访问与 RpcSs 服务关联的访问令牌，打开与 RpcSs 进程关联的服务的句柄，并扫描句柄表以识别与“NT AUTHORITY\SYSTEM”用户关联的访问令牌。在识别此令牌后，该令牌被复制以获得系统权限。

        此外，Clément Labro 在其题为“PrintSpoofer – 在 Windows 10 和 Server 2019 上滥用模拟特权”的博文中概述了从 SeImpersonatePrivilege 转移到“NT AUTHORITY\SYSTEM”的另一种方法，以及用于操作该技术的开源工具。

        不幸的是，当 Windows 传真服务尝试加载不存在的“ualapi.dll”文件时，它通过调用带有 LOAD_LIBRARY_SEARCH_SYSTEM32 标志的 LoadLibraryExW 函数来加载，这意味着在这种情况下服务不会遍历系统路径环境变量尝试加载 DLL  时。相反，该服务将仅检查“C:\Windows\System32\”目录中的 DLL 文件。虽然这对横向移动和持久性都有用，但在我们希望利用这种情况下的可写路径目录漏洞的情况下，它就没有用了。

开发后操作指南

        从操作的角度来看，本地权限提升的最理想目标之一是多用户系统，这些系统易于访问并被多个部门或用户的管理层广泛使用。

        Citrix 是这种设计模式的完美示例。在许多组织中，我们注意到当连接来自内部网络时，访问 Citrix 不需要多重身份验证。此外，组织内的任何员工通常都可以访问 Citrix，并且使用往往跨越多个部门。此外，Citrix 主机通常安装了大量应用程序，因此我们经常观察到这些主机上的可写路径权限提升问题。

        在获得内部立足点后，我们可以尝试通过 SOCKS 代理 Citrix 接收器桌面应用程序以绕过多因素身份验证，从而从内部角度连接到 Citrix。以这种方式访问 Citrix 通常提供了一种快速简便的方法，可以在风险最小的环境中实现初始横向移动。一旦实现对 Citrix 的访问，我们通常可以通过利用与路径中可写目录相关的配置问题来提升权限。

        使用 NT AUTHORITY\SYSTEM 级别访问权限，我们可以安装恶意安全支持提供程序，以记录对环境中的任何 Citrix 主机进行身份验证的所有用户的明文凭据。通常，这为我们提供了足够的访问权限来实现参与的目标。

        当针对具有成熟检测和响应能力的环境时，针对这些类型的共享用户系统特别有益。在这些类型的环境中，标准的红队攻击和横向移动技术将很快被检测到并导致驱逐。

整治指导

        可写路径问题的修复相对容易，因为只需要修改可写目录的权限。如果应用程序安装程序通过修改系统路径引入了可写路径漏洞，请考虑将问题报告给应用程序供应商，以便可以为所有客户修复问题。例如，CVE-2020-15264 涵盖了 Boxstarter 应用程序安装程序修改系统路径以在程序文件中包含可写目录的情况。

        从架构的角度来看，操作系统级别的用户之间的安全边界通常比虚拟机管理程序级别的虚拟机之间实施的安全边界要弱。因此，我们通常建议尽可能避免使用单系统多用户设计模式，尤其是在多层用户或部门访问系统的场景中。