CVE-2022-30190分析

在虚拟机执行了远程命令之后，返回恶意 WEB 服务器，可以看到恶意的 WEB 服务接收到了虚拟机发起的请求。

有一说一，居然发起了 12 次请求。

通过ProcMon也可以看到 12 次 Tcp 连接。

在进程链中可以找到WINWORD.EXE启动了msdt.exe进程，而且带上了一串参数。但是计算器居然是一个叫做 sdiagnhost.exe 的应用程序拉起的，中间出现了断链，无法跟踪到。

回过头来，看我们的恶意 WEB 界面。在这里可以看到我们 msdt 中的参数，说明参数是通过恶意 WEB 界面传递到WORD中，结果WORD拉起了 msdt.exe 去执行。

至于如何拉起的 msdt，则是因为 ms-msdt 协议的本地执行需要 msdt.exe，从进程行为可以看到查询 MS-MSDT协议如何处理，而且还能从注册表中看到默认处理的程序正是 msdt.exe。

之前自己用来 Bypass UAC 进行本地提权就是利用的 MSDT，没想到如今 MSDT 居然可以命令执行，说明当时研究的还是不彻底。MSDT作用在 Windows 自动化检测、修复故障的过程中，例如我们耳机突然间没有声音了，它会自动辅助我们进行声音系统的检测，测试软、硬件问题。Microsoft 在这个问题上所采用的方式是 WTP (Windows Troubleshooting Platform)[^2]。

在官方介绍 About-WTP 中有整个 WTP 系统的工作流程，其中提到有一个托管的 Windows PowerShell Runtime。那么可以大胆猜测这就是 PowerShell 命令注入的地点。下图是对微软的介绍进行理解后对原图进行了复刻所做出的示意图。

在图中可以看到，传递事件到 msdt.exe 时，msdt 仅通过 CMD 接收到了一串命令行参数。参数内容其实很容易理解，处理一个现有的 PCWDiagnostic 异常，自动跳过下一步(/skip force)，然后附加上了一个复杂的参数，也就是我们最核心的 Payload。msdt.exe 其实都没干啥，随后便将具体的工作交给了 sdiagnhost.exe，而 sdiagnhost.exe 则使用 PowerShell 脚本对异常进行处理。这里其实也能解释，我们的命令触发之后，进程调用链看起来直接中断，跳转到系统调用 sdiagnhost.exe 执行的 PowerShell 命令打开的计算器。

随便分析一下好了，首先从命令执行入手，不过 msdt.exe 和 sdiagnhost.exe 都是 VC 程序。。

使用 IDA 看一下，可以看到进入了 CScripteDiagNativeHost::RunScript函数，然后传递了某参数进入执行？

没办法呀，看不到动态获取的值和也没有猜出来结构体的类型和具体数值，直接上调试器看看，首先设置映像的调试器，偷懒直接用 gflags.exe 设置居然失败了。。。只好手动设置一下。

两者本身效果是一样的。

然后我们当然就逮到了所执行的脚本

在脚本中也找到了我们所传入的对应参数。

获取我们输入的含有 Payload 的参数 IT_BrowseForFile。

可以看到原本还对我们的参数进行过测试，但是结果替换”$”为”`$”好像没没啥作用[^3]？应该是还需要对”`”再加一个转义。。。

可以进入 Test-Selection 函数，看到 Test-Selection 函数还对我们的输出进行了检查，这回答了我们 Payload最后为什么需要“.exe”或者“.msi”结尾。

在脚本的最后，我们的这俩参数被传入 Update-DiagRootCause 中执行，不过在文件中没有找到这个函数，回想到上面的 WTP 结构，这个家伙不知道在哪里找了，不过没有关系，我们直接调试这段 PowerShell 的执行就好了。

注：这个使用了Update-DiagRootCause 命令，该命令也是4条特殊命令之一，用于报告root cause 的状态。注释中写道该命令会触发调用 RS_ 脚本，-parameter 指定的字典会被作为参数传给脚本。导致第二次调用 RunScript() 方法，并且参数中的 -TargetPath 可控，进而触发了漏洞。[^4]

这里可不是指的调试 PowerShell 脚本，而是直接利用 PoerShell 是由 C# 驱动的，直接调试所依赖的 DLL 和对应函数。

既然是调试 .Net 程序，肯定要用到无敌的 dnSpy，设置一下 Debugger。

我也不知道为啥要设置这俩系统变量，我看到别人要设置[^4]。。就跟着设置一下 dnSpy 调试所需的变量。。。

然后呢，我们在启动 sdiagnhost.exe 的时候断住还不行，这时候我们还要找到上面执行脚本时所进入的函数。刚好根据脚本中的提示，我们找到 Microsoft.Windows.Diagnosis.SDHost.dll 的 RunScript 函数，下断点。接着点击继续，正好断住。

调试代码中，可以看到，上面 PowerShell 的两个被我们用户控制的参数，传递到 this.m_Ps.Commands.AddScript(text) 中作为参数，而没有过滤，或者说过滤的不充分，所以达到了命令注入的目的。

至此，整个利用链清晰了。首先利用CVE-2021-40444漏洞的原理，加载远程模板，该远程模板包含 ms-msdt 协议，使得WORD拉起 msdt.exe，进行含参调用，在处理参数的时候，由于微软的疏忽，导致 PowerShell 命令被攻击者污染，结果被 msdt.exe 按照 WTP 框架传递进 sdiagnhost.exe，最终 执行了恶意的 PowerShell 代码。

一直摸鱼到最近才看这个漏洞，一是因为之前摸过msdt，不愿意再去看，二是一翻分析文章就能看到yara规则的查杀，实在心累~~（就不能让孩子试试钓鱼嘛？打不动点呀）~~

不过为了优雅，哥们儿重构一下 Python 的利用脚本，顺便用自己的简化 Payload。（重复造轮子）

1.CVE-2022-30190-follina-Office-MSDT-Fixed
2.Windows Troubleshooting Platform | Microsoft Docs
3.CVE-2022-30190 MSDT 代码注入漏洞分析 (seebug.org)
4.CVE-2022-30190：Microsoft Windows 支持诊断工具 (MSDT) 远程代码执行

长按识别二维码关注我们