CVE-2019-13382:SnagIt本地权限提升漏洞深度解析

本文详细分析了SnagIt软件中的CVE-2019-13382本地权限提升漏洞,涉及TechSmith Uploader服务的不安全文件移动操作,通过符号链接实现SYSTEM权限获取,包含完整的漏洞识别、利用过程及修复时间线。

CVE-2019-13382:SnagIt本地权限提升漏洞

版本: Snagit 2019.1.2 Build 3596
测试操作系统: Windows 10 1803 (x64)
漏洞: 通过不安全文件移动实现的SnagIt Relay Classic Recorder本地权限提升
此漏洞由Capital Group安全测试团队的Marcus Sailler、Rick Romo和Gary Muller共同发现

漏洞概述

每30-60秒,TechSmith Uploader服务(UploaderService.exe)会检查“C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations”文件夹中是否存在“*.xml”格式的演示文件。如果发现无效文件,该服务会以SYSTEM权限将该文件移动到“C:\ProgramData\Techsmith\TechSmith Recorder\InvalidPresentations”。

由于低权限用户对QueuedPresentations和InvalidPresentations文件夹拥有完全控制权,攻击者可以在QueuedPresentations文件夹中创建无效演示文件,并在InvalidPresentations文件夹中为该文件名创建指向特权位置的符号链接。

当服务检查演示文件时,它会将文件从QueuedPresentations文件夹移动到InvalidPresentations文件夹。在此过程中,服务会触发符号链接,并将新文件写入受保护的位置,且低权限用户对该内容拥有完全控制权,从而导致权限提升至NT AUTHORITY\SYSTEM。

识别与利用

在评估软件权限提升漏洞时,找到起点通常很困难,因为存在多种不同的原语和漏洞类别。我的方法通常从基础开始,逐步增加复杂性。此过程通常包括运行PowerUp等工具,以识别各种简单(但常见)的错误配置。

如果未返回有趣的结果,下一步通常是寻找逻辑漏洞,特别是滥用符号链接/挂载点/硬链接原语。为了快速识别可能通过链接原语利用的潜在漏洞,我们需要确定操作系统中特权进程(通常是SYSTEM)与低权限用户控制的文件夹或文件交互的位置。这种逻辑在大多数逻辑漏洞中都成立,即有趣的攻击面与特权进程使用低权限用户控制的资源相关。

在寻找此类漏洞时,我通常首先在SYSTEM进程和常被滥用的文件系统位置(如C:\ProgramData、C:\Windows\Temp和C:\Users<username>\AppData)上运行Process Monitor并设置过滤器。此类过滤器可能如下所示:

应用Process Monitor并观察输出几分钟后,明显发现“UploaderService.exe”正在查询“C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations”目录中的XML文件:

查看该文件夹的DACL,还发现“BUILTIN\Users”具有写访问权限:

这特别有趣,因为特权SYSTEM进程(UploaderService.exe)正在低权限用户具有读/写访问权限的目录中查找文件。有了这些信息,下一步是给“UploaderService.exe”提供一个XML文件,并观察会发生什么。

正如预期的那样,“UploaderService.exe”检查“C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations”中的XML文件,并找到我们创建的文件:

接下来的问题是,“UploaderService.exe”如何处理我们的XML文件?它会读取并处理内容吗?会将其放置在其他地方吗?查看Process Monitor的其余输出可以为我们解答这个问题。在这种情况下,“UploaderService.exe”会获取“C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations”中的任何XML文件,并确定XML演示文件是否有效。由于我们只是将“1”回显到XML文件中,服务可执行文件确定“1.xml”是无效演示文件,并将其移动到“C:\ProgramData\Techsmith\TechSmith Recorder\InvalidPresentations\1.xml”:

查看“C:\ProgramData\Techsmith\TechSmith Recorder\InvalidPresentations”目录,“BUILTIN\Users”也具有读/写访问权限:

此时,我们已经确定SYSTEM进程(UploaderService.exe)正在检查用户控制的目录中的XML文件。当找到文件时,特权进程会获取攻击者提供的XML文件,并将其从QueuedPresentations文件夹移动到InvalidPresentations文件夹,同时保留原始文件名。

为什么这很有趣?这提供了在移动文件操作期间使用符号链接来完成特权文件写入的机会。你可能会问,如何实现?工作流程如下:

  1. 在“C:\ProgramData\Techsmith\TechSmith Recorder\InvalidPresentations\1.xml”上创建指向“C:\Windows\System32\ualapi.dll”的符号链接。

    需要注意的是,“C:\Windows\System32\ualapi.dll”不存在。这是我们植入的DLL,以获取SYSTEM代码执行权限。 由于进程是特权“SYSTEM”,它将具有写入此文件的正确权限。

  2. 将虚拟xml文件写入“C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations\1.xml”。

  3. 当“UploaderService.exe”检查“C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations”中的XML文件时,它会找到“1.xml”并将其移动到“C:\ProgramData\Techsmith\TechSmith Recorder\InvalidPresentations\1.xml”。在此过程中,它会触发我们的符号链接,并将文件移动到“C:\Windows\System32\ualapi.dll”(同时保留原始DACL)。

理论上,这应该可行。让我们测试一下!对于符号链接,我使用了James Forshaw的符号链接测试工具库中的“CreateSymlink.exe”。我们需要做的就是在“C:\ProgramData\Techsmith\TechSmith Recorder\InvalidPresentations\1.xml”上放置一个指向“C:\Windows\System32\ualapi.dll”的符号链接,然后创建“C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations\1.xml”:

创建符号链接和虚拟XML文件后,我们等待60秒,让“UploaderService.exe”检查QueuedPresentations文件夹。当它检查时,它会找到我们的“1.xml”文件,并尝试将其移动到“C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml”。在此过程中,它会触发我们在“C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml”上的符号链接,并将其写入“C:\Windows\System32\ualapi.dll”:

然后我们可以确认“C:\Windows\System32\ualapi.dll”的存在:

这很好,但新创建的“ualapi.dll”文件不应该简单地继承父文件夹(C:\Windows\System32)的权限并阻止低权限用户写入吗?这是我最初的想法(在检查文件的DACL之前),但“UploaderService.exe”使用MoveFileW()。根据文档,MoveFileW()在同一卷上移动文件时会保留原始DACL:

虽然没有明确说明,但可以推断,如果文件未跨卷移动,则会保留DACL。这意味着当“UploaderService.exe”触发“C:\ProgramData\TechSmith\TechSmith Recorder\InvalidPresentations\1.xml”上的符号链接,并尝试将原始文件移动到“C:\Windows\System32\ualapi.dll”时,它会保留“1.xml”的原始DACL。由于它是由低权限用户创建的,因此其DACL将低权限用户作为所有者,并具有“FullControl”权限:

此时,我们现在拥有“C:\Windows\System32\ualapi.dll”,并允许我们的低权限用户写入。这意味着我们可以简单地用我们选择的有效负载覆盖新创建的ualapi.dll文件。在这种情况下,有效负载在加载时启动cmd.exe。

现在,我们的有效负载位于C:\Windows\System32\ualapi.dll中。此DLL在假脱机服务启动时加载。对于PoC,剩下的就是重新启动主机以使假脱机服务重新启动。此外,可以使用CollectorService在不重新启动的情况下加载DLL。由于这是PoC,这是留给读者的练习。

一旦主机重新启动,“spoolsv.exe”将以SYSTEM权限从C:\Windows\System32\ualapi.dll加载我们的有效负载,从而导致权限提升:

漏洞利用视频可以在这里找到:https://www.youtube.com/watch?v=V90JRwlaHRY&feature=youtu.be

此漏洞已在SnagIt版本2019.1.3、2018.2.4和13.1.7中修复,CVE编号为CVE-2019-13382。修复涉及在移动文件时使用_time64,并结合检查重解析点(FSCTL_GET_REPARSE_POINT)。如果存在重解析点,则将其删除。

披露时间线

尽管SpecterOps致力于透明化,但我们承认攻击者在公开后采用新攻击技术的速度。这就是为什么在公开新漏洞或攻击技术之前,我们通常会通知相应的供应商,提供充足的时间来缓解问题,并通知选定的、受信任的供应商,以确保检测可以尽快交付给他们的客户。

  • 2019年6月19日:与Capital Group的安全测试团队共同识别漏洞
  • 2019年6月20日:与Capital Group开始联合披露。开设支持案例,请求TechSmith安全团队的联系信息
  • 2019年6月21日:案例分配给处理人员,新评论称细节可以上传到当前案例,并将转发给安全团队
  • 2019年6月21日:完整报告、PoC代码和演示视频上传到开放支持案例
  • 2019年6月25日:TechSmith确认漏洞并提供临时修复建议。TechSmith还要求在公开披露前通知
  • 2019年6月25日:告知TechSmith公开披露将在初始报告后90天进行,并注明如果需要会考虑延期
  • 2019年7月2日:TechSmith表示修复版本已完成,并计划在7月底前部署,同时询问我们是否会验证修复
  • 2019年7月2日:告知TechSmith我会验证修复
  • 2019年7月3日:TechSmith提供私有的修复版本
  • 2019年7月9日:告知SnagIt基于测试,修复似乎足够
  • 2019年7月23日:发布补丁,问题公开披露
comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计