概述
在这个两部分的系列中，我们讨论了两个我们在红队操作中常见的Windows本地提权漏洞。由于这些问题在具有成熟安全程序的组织中很普遍，因此这些问题尤其引人关注。此外，利用此问题不太可能触发常用的端点和网络监控产品中的检测。
这些问题的根本原因是常见的系统配置错误，这样使得识别和利用这些问题非常地可靠。相比之下，传统的基于内存破坏的本地提权漏洞通常需要根据目标使用的操作系统版本或系统构建使用固定的偏移量。在本系列的第一部分中，我们涵盖了系统路径环境变量中可写目录引起的本地提权问题。

可写系统路径目录漏洞
可写路径本地提权漏洞来自于系统管理员或应用程序安装程序修改系统路径环境变量以包括非特权用户可写入的目录的情况。
此问题的典型根本原因是应用程序安装程序或管理员在适当的目录（e.g.“Program Files”)之外安装应用程序，然后随后修改系统路径环境变量以指向已安装的目录。因此，创建的目录从父目录继承了危险权限。

其中一个例子是“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文件。由于此文件在服务器操作系统上不存在，因此它最终会遍历系统路径以查找该文件。从操作视角来看，攻击者最好的情况是非特权用户可以触发此操作而无需要求重新启动目标系统。
Clément Labro发现的NetMan服务就是这样一个例子，它允许非特权用户通过公开的COM接口与其交互。重要的是，根据Microsoft的说法，这种行为不构成Windows中的漏洞，因为系统正在执行搜索路径所需的适当操作。但是，如果第三方应用程序安装程序在安装期间修改了系统路径环境变量并引入了可写路径特权问题，则可能符合应用程序安装程序中的漏洞/CVE。
然而，从利用角度来看，情况要复杂得多，因为易受攻击的服务可能因目标系统使用的操作系统版本而异。在下表中，我们概述了三个可用于通过DLL的加载来权限提升并且技术可行的相应操作系统版本。

当其中一个服务加载攻击者提供的DLL时，Windows加载器将调用DllMain函数，而不管目标服务调用哪些导出函数。当执行DllMain时，攻击者可以将自己添加到本地管理员组中。虽然这通常对于概念证明漏洞利用来说没问题，但从操作安全性角度来看通常并不理想。修改本地管理员组成员身份可以创建事件日志条目，安全工具可以对其进行警报。更具操作性合理的方法是在特权服务上下文中执行远程管理工具（例如Cobalt Strike的beacon有效载荷）。
尝试将beacon加载到劫持的进程中可能会在某些情况下导致死锁。操作员常犯的一个常见错误是从DllMain内部在劫持进程的上下文中调用反射式加载器。因为Windows加载器在执行DllMain函数期间持有加载器锁定机制，所以从DllMain内部调用反射式加载器，当反射式加载器也调用LoadLibrary并等待加载器锁定被释放时，会导致进程死锁。解决此问题最简单的方法是等待服务在未激活加载器锁定时调用与劫持DLL相关联的导出项。攻击者可以对相应服务可执行文件进行逆向工程以揭示受害者服务使用哪些导出项。

利用Windows任务计划程序进行利用
在他标题为 “Windows 10 – Task Scheduler service – Privilege Escalation/Persistence through DLL planting” Gregory Draperi概述了一种通过针对Windows任务计划程序服务进行攻击来利用可写路径漏洞的方法。Gregory发现该服务在启动时尝试通过调用LoadLibrary函数加载WptsExtensions.dll文件。利用此方法的缺点是触发目标服务行为需要重新启动系统，因为该服务仅在系统启动时尝试加载DLL [4]。
利用此向量进行攻击相对简单。攻击者只需将恶意DLL放置到可写路径目录中，并等待或触发系统重启即可。但是，在Windows Server操作系统上，非管理员用户没有权限执行关闭或重新启动操作。此外，在生产系统上执行重新启动通常是不明智的，并且可能对红队操作安全性产生不良影响。

利用NetMan服务
Clément Labro在他标题为“Windows Server 2008R2-2019 NetMan DLL Hijacking,” 的文章中[1]概述了他对Windows NetMan服务及其如何被利用进行DLL劫持的研究。Labro确定了NetMan服务公开COM接口中暴露出来的一个COM接口，非特权用户可以访问该接口。
通过使用暴露出来的COM接口枚举连接属性，Labro可以触发调用LoadLibrary以加载“wlanapi.dll”文件[1]。虽然“wlanapi.dll”文件默认情况下不存在于任何受支持的Windows Server操作系统上，但它存在于Windows 10上，只有在执行权限提升针对Windows Server时才可行.然而，即使在服务不能直接用于通过此向量进行本地提权的情况下，攻击者仍然可以使用服务来执行横向移动或建立持久性。
在这种情况下，利用相对简单，只需将攻击者的“wlanapi.dll”文件复制到可写路径目录中。在他的文章中，Labro指出，在Windows Server 2012 R2上，该服务将尝试加载名为“wlanhlp.dll”的文件[1]；然而，Praetorian的测试表明，该服务现在尝试加载“wlanapi.dll”。接下来，攻击者需要利用Labro提供的代码通过COM枚举网络适配器来触发DLL加载尝试[1]。

IKEEXT服务的可疑案例
在一篇名为“Triaging a DLL Planting Vulnerability” [3]，微软安全响应中心（MSRC）团队描述了他们在审查各种类型的DLL植入问题时遵循的过程。 MSRC表示，“PATH目录DLL植入的DLL植入问题被视为‘不修复’。”[3]微软似乎在IKEEXT服务[2]的情况下偏离了这个声明的政策。
在这种情况下，微软似乎通过将LoadLibrary调用修改为使用设置为仅在System32目录中搜索“wlbsctrl.dll”文件的LOAD_LIBRARY_SEARCH_SYSTEM32标志调用LoadLibraryEx来解决了IKEEXT服务DLL劫持问题，如下图所示。

然而，由于该服务仍然会在启动时尝试加载不存在的DLL，因此该服务仍然可用于利用任意写入问题或执行横向移动，正如Dwight Hohnstein[7]所记录的那样。

替代利用技术
之前我们说过利用可写路径漏洞的最简单方法是识别以“NT AUTHORITY\SYSTEM”运行并通过遍历系统路径来尝试加载不存在DLL的服务。但是，还存在一种替代方法，即对以“NT AUTHORITY\NETWORK SERVICE”或“NT AUTHORITY\LOCAL SERVICE”身份运行的服务执行相同的攻击。 Windows服务默认授予SeImpersonatePrivilege权限[5]，如下图所示。

Yarden Shafir和Alex Ionescu在他们的文章“Faxing Your Way to SYSTEM — Part Two”[5]中概述了他们对Windows传真服务的研究，文中记录了他们发现Windows传真服务在启动时尝试加载不存在的DLL。此外，Windows传真服务配置为任何用户都可以触发服务的启动，如下图所示。

由于Windows传真服务默认被授予SeImpersonatePrivilege权限，因此可以首先创建一个命名管道，然后诱导更高特权的服务访问命名管道以模拟客户端服务[5]。在文章中，作者利用了James Foreshaw在他的帖子“Sharing a Logon Session a Little Too Much.”[9]中记录的一种技术。该技术涉及创建命名管道并使用\localhost\路径连接，从而触发SMB网络重定向器的身份验证。
然后，作者利用模拟来访问与RpcSs进程关联的服务相关联的访问令牌，并扫描句柄表以识别与“NT AUTHORITY\SYSTEM”用户关联的访问令牌[5]。在识别出该令牌后，将复制该令牌以获得SYSTEM权限[5]。
此外，在他的名为“PrintSpoofer – Abusing Impersonation Privileges on Windows 10 and Server 2019”的博客文章[10]中，Clément Labro概述了从SeImpersonatePrivilege移动到“NT AUTHORITY\SYSTEM”的替代方法，并提供了一种操作化该技术的开源工具[11]。
不幸的是，当Windows传真服务尝试加载不存在的“ualapi.dll”文件时，它会通过设置了LOAD_LIBRARY_SEARCH_SYSTEM32标志的LoadLibraryExW函数进行调用，这意味着在这种情况下，服务将不会遍历系统路径环境变量来尝试加载DLL [12]。相反，该服务仅检查位于“C:\Windows\System32\”目录中的DLL文件。虽然这对横向移动和持久性都有用，但在这种情况下寻找利用可写路径目录漏洞是无用的。

后期利用操作指南
从操作角度来看，本地提权最理想的目标之一是易于访问且被多个部门或管理层用户广泛使用的多用户系统。
Citrix就是这种设计模式的完美例子。在许多组织中，我们注意到连接源自内部网络时访问Citrix不需要多因素身份验证。此外，Citrix通常可被组织内任何员工访问，并且使用通常跨越多个部门。此外，Citrix主机通常安装了大量应用程序，并且由于此原因我们经常观察到可写路径提权问题。
获得内部立足点后，我们可以尝试通过SOCKS代理Citrix接收器桌面应用程序从内部角度连接到Citrix以绕过多因素身份验证。以这种方式访问Citrix通常提供了一种快速简便的方式，在最小化风险的情况下实现环境内初步横向移动。一旦获得对Citrix的访问权限，我们通常可以通过利用与路径相关的可写目录配置问题来进行权限提升。
通过NT AUTHORITY\SYSTEM级别访问后，我们可以安装恶意安全支持提供程序以记录所有用户在任何Citrix主机上进行身份验证时的明文凭据。通常情况下，这为我们提供了足够的访问权限来实现业务目标。
针对这些共享用户系统特别有益的是针对具有成熟检测和响应能力的环境进行攻击时。在这些类型的环境中，标准的红队攻击和横向移动技术将很快被检测到并导致驱逐。

整改指南
可写路径问题的整改相对容易，只需修改可写目录的权限即可。
如果应用程序安装程序通过修改系统路径引入了可写路径漏洞，请考虑向应用程序供应商报告此问题，以便为所有客户解决此问题。例如，CVE-2020-15264涵盖了Boxstarter应用程序安装程序修改系统路径以包括可写目录的情况[13]。
从架构角度来看，操作系统级别上用户之间的安全边界通常比在虚拟机级别上强制执行的安全边界要弱。因此，我们通常建议在可能的情况下避免单系统多用户设计模式，特别是在多个用户层或部门访问系统的情况下。

结论
在第一部分中，我们讨论了可写路径权限提升漏洞背后的基本概念，记录了利用方法，并提供了有关在红队参与期间利用此技术的操作指南。在第二部分中，我们将讨论另一种常见的本地权限提升向量，并建议通过Cobalt Strike的beacon来操作此技术。

引用
[1] https://itm4n.github.io/windows-server-netman-dll-hijacking/
[2] https://medium.com/bugbountywriteup/ikeext-dll-hijacking-3aefe4dde7f5
[3] https://msrc-blog.microsoft.com/2018/04/04/triaging-a-dll-planting-vulnerability
[4] http://remoteawesomethoughts.blogspot.com/2019/05/windows-10-task-schedulerservice.html
[5] https://windows-internals.com/faxing-your-way-to-system/
[6] https://www.reddit.com/r/hacking/comments/b0lr05/a_few_binary_plating_0days_for_windows/
[7] https://posts.specterops.io/lateral-movement-scm-and-dll-hijacking-primer-d2f61e8ab992
[8] https://www.a12d404.net/windows/2019/01/13/persistance-via-path-directories.html
[9] https://www.tiraniddo.dev/2020/04/sharing-logon-session-little-too-much.html
[10] https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/
[11] https://github.com/itm4n/PrintSpoofer
[12] https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexa
[13] https://nvd.nist.gov/vuln/detail/CVE-2020-15264
From:https://www.praetorian.com/blog/red-team-local-privilege-escalation-writable-system-path-privilege-escalation-part-1/