背景

微软在5月30日发布了一则临时漏洞公告，披露了Microsoft Support
Diagnostic Tool (MSDT)模块的一个命令注入导致的远程代码执行漏洞，编号为CVE-2022-30190。经过分析，我们发现该漏洞利用方式和去年的CVE-2021-40444比较类似，都是通过word文档中的OLE对象让office程序加载一个恶意html网页并渲染，而该网页中的js脚本则使用重定向功能触发msdt协议最终利用命令注入漏洞执行恶意代码。

漏洞分析

word文档加载html

与CVE-2021-40444的样本一样，首先需要构造一个OLE对象让office程序加载一个html文件。

html触发MSDT协议

这里也与CVE-2021-40444类似，在html文件中，利用js重写location.href的方式，触发对应的URL协议，这里我们使用ms-msdt触发MSDT协议。

可以看到，我们指定协议之后也传递了很多参数，其中IT_BrowseForFile参数即是本次漏洞命令注入的关键，这里我们直接传递命令$(Start-Process('calc')打开一个计算器。

MSDT命令注入

根据微软的相关文档，MSDT模块是通过Windows Troubleshooting Platform（WTP）框架实现的，结构图如下：

当我们使用MSDT协议时，实际上会启动一个msdt.exe进程，同时将相关参数传递过去。然后msdt.exe进程根据参数调用sdiagnhost.exe的相关接口，由于我们通过id参数指定了PCWDiagnostic模块，所以这里msdt.exe进程会使用sdiagnhost.exe提供的RunScript接口运行TS_ProgramCompatibilityWizard.ps1这个PowerShell脚本，并将参数param后面的字符串作为脚本参数传入。

进一步查阅TS_ProgramCompatibilityWizard.ps1脚本文件：

在一些函数定义及初始化之后，脚本首先通过Get-DiagInput命令获取传入的IT_BrowseForFile参数并保存到局部变量$selectedProgram里面，其中包含有我们的注入命令。

这个参数是一个文件路径，脚本随后会调用函数Test-Selection对其进行校验：

可以看到，Test-Selection首先使用test-path命令检测路径是否存在，然后判断路径是否指向exe或msi文件。对于后面的检测，我们简单的提供一个exe后缀即可，而对与前面的检测，我们也可以使用大量相对路径符../让路径指向系统的根目录之外，即超出根目录范围，让test-path命令报错并返回True，从而通过检测：

最后，脚本使用Update-DiagRootCause命令并将参数$selectedProgram传入，触发命令注入。

补丁对比

6月正式补丁之前

根据测试，虽然微软在6月份补丁日之前还未发出正式补丁，但是如果将office更新到最新版本（这里使用的是office 2019 2205），恶意docx文件并不会触发MSDT命令注入，猜想是微软将其作为非安全问题进行了一定修复。

通过进一步分析发现，微软的补丁修改了Mso30win32client.dll的相关函数，让代码在加载mshtml模块后，额外进行了一个配置：

然后，当mshtml解析加载的html文件时，检测函数CMarkup::DontRunScripts会根据上面的配置返回True，拒绝执行html文件中的js脚本，从而避免了漏洞的触发。

而奇怪的是，如果把docx保存为rtf格式的话，依然可以触发漏洞，怀疑可能rtf的解析路径与代码与docx不同导致。

6月正式补丁之后

CVE-2022-30190的正式补丁主要针对msdt.exe进行修改：

增加了ValidateInputInteractionValue进行参数的校验，如果发现注入相关的符号$(或在下面的正则匹配时发现恶意符号，则返回错误，终止程序的执行。

总结

CVE-2022-30190的触发方式与利用过程本质上和CVE-2021-40444是相同的，可以看做是后者补丁的绕过。这类通过url与html的利用方式，也与从CVE-2017-0199开始的一系列URL Moniker漏洞有一定的相似之处（CVE-2017-0199、CVE-2017-8570、CVE-2017-8759、CVE-2018-8174、CVE-2020-0674）。可以看到，在office内存破坏漏洞越难越难以利用的今天，通过远程加载功能去触发逻辑漏洞的方式越来越被攻击者看重，但是看来微软并未完全封堵住这一攻击面，那么接下来很可能还会有类似的漏洞被发现。