CVE-2019-13382:SnagIt本地权限提升漏洞分析与利用

本文详细分析了SnagIt软件中的本地权限提升漏洞CVE-2019-13382,涉及符号链接滥用和文件移动操作的不安全实现,最终导致低权限用户获得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 Service (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)与低权限用户控制的文件夹或文件交互的位置。这种逻辑在大多数逻辑漏洞中都成立,即有趣的攻击面与特权进程使用低权限用户控制的资源相关。

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

应用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的Symbolic Link Testing Tools仓库中的“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”将从C:\Windows\System32\ualapi.dll加载我们的有效负载作为SYSTEM,从而导致权限提升:

漏洞利用视频可以在这里找到: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 设计