CVE-2019-13382: SnagIt本地权限提升漏洞 | enigma0x3
版本: 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\
当应用进程监视器并观察几分钟输出后，很明显“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文件？它会读取并解析内容吗？还是把它放到其他地方？ 查看进程监视器的其余输出可以为我们解答这个问题。在这种情况下，“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”不存在。这是我们为了以SYSTEM权限执行代码而放置的DLL。
- 由于进程是特权的“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”，并且允许我们的低权限用户写入。这意味着我们可以简单地用我们选择的payload覆盖新创建的ualapi.dll文件。在本例中，payload在加载时会启动cmd.exe。
现在我们的payload位于C:\Windows\System32\ualapi.dll。这个DLL在spooler服务启动时被加载。对于PoC，剩下的就是重启主机以使spooler服务重新启动。此外，也可以使用CollectorService在不重启的情况下加载DLL。由于这是一个PoC，这留给读者作为练习。 一旦主机重启，“spoolsv.exe”将以SYSTEM权限从C:\Windows\System32\ualapi.dll加载我们的payload，从而实现权限提升：
漏洞利用视频可以在这里找到：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日：补丁发布，问题公开披露