CVE-2019-13382:SnagIt 本地权限提升漏洞分析与利用
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)与低权限用户控制的文件夹或文件交互的位置。
在寻找此类漏洞时,我通常从运行 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 文件夹,同时保留原始文件名。
为什么这很有趣?这提供了在移动文件操作期间使用符号链接来完成特权文件写入的机会。如何实现?工作流程如下:
在"C:\ProgramData\Techsmith\TechSmith Recorder\InvalidPresentations\1.xml"上创建指向"C:\Windows\System32\ualapi.dll"的符号链接
需要注意的是,"C:\Windows\System32\ualapi.dll"不存在。这是我们植入的 DLL,以获取 SYSTEM 代码执行权限由于进程是特权"SYSTEM",它将具有写入此文件的正确权限。
将虚拟 xml 文件写入"C:\ProgramData\Techsmith\TechSmith Recorder\QueuedPresentations\1.xml"
当"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 将低权限用户作为拥有"完全控制"权限的所有者:
此时,我们现在拥有允许低权限用户写入的"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)。如果存在重解析点,则将其删除。
披露时间线
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 日:发布补丁,问题公开披露更多精彩内容 请关注我的个人公众号 公众号(办公 AI 智能小助手)公众号二维码
- 办公AI智能小助手
评论