聊下最近的 CVE-2022-30190

11小时之前2022年06月13日
漏洞分析 · 404专栏

作者：heige@知道创宇404实验室
原文链接：https://mp.weixin.qq.com/s/tb0K-qLcZo-9OeW3KsIrTg

最近曝光的在野0day挺多的，看起来又为今年的年终的总结提供不少弹药，看到这个漏洞我在朋友圈里简单评论下：

CVE-2022-30190 (Follina) 这个漏洞在我的标准里可以算是"神洞"了，品相远比CVE-2021-40444要高。每次看到这种漏洞都有着“惋惜”的感觉/::-| ... 比较有意思8挂的是这个漏洞是crazyman 4月11日看到样本后在4月12日提交给MSRC，结果微软回复了个经典用语：“I finally had time to look at this critically and have decided it is not a security related issue”，想起那些年我提交的那些被忽视的“猥琐流”漏洞...

CVE-2021-40444 与 CVE-2022-30190

上面说品相比CVE-2021-40444要好，主要是看的实战场景，那是因为CVE-2021-40444不太好绕过“受保护视图”机制导致存在一个“启用编辑”的那个提示，也就是需要额外的点击下！而CVE-2022-30190利用并没有这个提示，这个是因为漏洞触发在ms-msdt:// 伪协议里，直接利用转跳机制，而没有触发“受保护视图”机制，这个也算是一个小缺陷吧！

从技术角度上看，CVE-2021-40444 与 CVE-2022-30190都算是非常精妙的“猥琐流”的应用层逻辑漏洞，这种漏洞类型与内存型有很多天然的优势。当然实战效果下CVE-2021-40444应该说是一个漏洞集合，利用CAB控件调用时导致目录穿越，实现了inf文件下载（相对明确的文件名及路径，并且不被删除），再通过.cpl去加载这个inf文件实现命令执行操作，具体分析可以看由sunglin@知道创宇404实验室 写的详细分析：https://paper.seebug.org/1718/

CVE-2022-30190 则是一个ms-msdt:// 伪协议过程里最终由于PowerShell.AddScript()导致的PS代码注入漏洞导致的，漏洞原型可以理解为：

PowerShell powerShellCommand = PowerShell.Create();
powerShellCommand.AddScript("ls -test $(iex('mspaint.exe'))");
var result = powerShellCommand.Invoke();

当然整个流程要分析清楚还是相对比较复杂的，详细分析可以参考由 HuanGMz@知道创宇404实验室 带来的分析：https://paper.seebug.org/1913/

比较有意思的是，微软的开发者在PS文件调用对其中一个参数是有过意识的过滤的：

$appName = [System.IO.Path]::GetFileNameWithoutExtension($selectedProgram).Replace("$", "$")

从404分析文章来看这个过滤写法是错误的而且没有起到作用，正确的写法为：

$appName = [System.IO.Path]::GetFileNameWithoutExtension($selectedProgram).Replace("`$", "``$")

当然这个是selectedProgram就ok ，所以我事后在想是不是这个过滤点给漏洞发现者带来了灵感？！

这个漏洞方式非常像以前研究IE浏览器调用本地的html/js导致的Dom Xss，只是随着时间的迁移现在微软都是.net/PS混合调用的写法了，而这种写法在office等系列包括去年的漏洞人气王Exchange，所以我觉得这种PS代码注入的问题很可能再次出现，当然就MSDT这个功能的实现下就有不少的PS文件调用，从这个漏洞模型关注

Get-DiagInput, Update-DiagReport, Update-DiagRootCause, Write-DiagProgress

这4个命令，如果可以允许参数提交（Get-DiagInput）就有可能触发 ...

CVE-2021-40444 与 CVE-2022-30190 有一个共同的特点，其实这个也算是攻击面的理解问题，因为在IE年代这种漏洞都是首先考虑从IE浏览器去触发的，而现在都转为通过office去调用触发，所以理论上IE的攻击面（在多年以前的《WEB2.0下的渗透测试》提到了无处不在的浏览器，就涉及到这些攻击面的理解问题）并没有随着IE的消失而消失，而是发生了转移。这个让我想起了当年的mdb漏洞，当年微软认为mdb很少有人直接去打开所以拒绝修复mdb文件的漏洞，直到有人使用word去调用mdb触发 ...

当然理解好这点对新的0day样本的监控识别是非常有意义的？！

对于这种“神洞”，我每次看到这种“被爆”就会觉得惋惜（虽然这个漏洞有微软这个神助攻硬是把他延续到了6月，如果从阴谋论角度去思考微软是故意忽视的，那就有点细思极恐的味道了～～），在10+年前还在发明xss/json hijack获取用户信息的套路时，顺带实现了0day保护的玩意，当时实战效果时非常不错的，当年我在80vul网站上挂了1年多的只有一个朋友反馈他使用firefox noscript有个提示外没有其他被发现的痕迹，甚至后来一度“产品化”，只是可惜是：大家首要想要的是0day，而不仅仅是一个0day保护程序～～～ [当然这个是另外一个角度的话题了] 然而时隔这么多年这种意识到现在好像还没有太大的改变 ...

背后的8卦

大家都知道我的，相比漏洞我更加喜欢关注漏洞背后的8卦：这个漏洞最早是由国内研究员 crazyman 4月11日分析VT样本（2022/04/11上传，俄罗斯主题相关 https://www.virustotal.com/gui/file/710370f6142d945e142890eb427a368bfc6c5fe13a963f952fb884c38ef06bfa/details ）于4月12日报告给微软，比较有戏剧性的是微软4月21日就关闭了这个case，并给出了“I finally had time to look at this critically and have decided it is not a security related issue”经典回复。

直到5月27日有国外研究者也注意到了VT上另外一个样本（5月26日提交 https://www.virustotal.com/gui/file/4a24048f81afbe9fb62e7a6a49adbd1faf41f266b5f9feecdceb567aec096784/details ）并把msdt调用部分的代码分享在推特上，随即引起技术社区的关注，微软最终在5月30日分配CVE-2022-30190这个CVE，并发布了临时处理方式包括Defender及临时注册表删除msdt协议支持，只是根据我们404小伙的测试简简单单加点那啥就能绕过defender 很尴尬～～

更加尴尬是事情还没有结束，国外研究员@j00sean 又发现了一些关于新的“MSDT path traversal 0day”，再结合一些其他的伪协议可以通过PDF、浏览器触发，只是利用需要多次点击确定（这点确实比较鸡肋），提交给微软后“果不其然”的再次被拒绝，更加尴尬的是MSRC建议他提交给google（因为chromium可以触发 ）～～～

https://twitter.com/j00sean/status/1534124426874261504

这又让我想起了当年d4rkwind发现的mhtml漏洞https://paper.seebug.org/papers/old_sebug_paper/pst_WebZine/pst_WebZine_0x05/0x05_IE%E4%B8%8BMHTML%E5%8D%8F%E8%AE%AE%E5%B8%A6%E6%9D%A5%E7%9A%84%E8%B7%A8%E5%9F%9F%E5%8D%B1%E5%AE%B3.html，因为当时是影响到Gmail https://packetstormsecurity.com/files/97563/Hacking-With-MHTML-Protocol-Handler.html （也是这个文章导致CVE-2021-40444刚出来的时候，很多老外重新提到了这篇文章），所以顺带报告了google，然后google说这个漏洞应该由微软处理（这个处理是正确的），而且全程给不厌其烦，苦口婆心的跟微软沟通！（只是我不记得最后微软有没有给CVE了，那个时代大家都是摇滚青年，不太在乎，直接披露就完事了）

马上就到6月的补丁日，微软会不会真正修复，怎么修复那么我们拭目以待咯～～

最后提一点关于MSDT这个点的“考古”：

https://doublepulsar.com/follina-a-microsoft-office-code-execution-vulnerability-1a47fce5629e 在2020年8月的一篇论文里有提到MSDT本身参数功能调用UNC实现执行的方式：

https://benjamin-altpeter.de/doc/thesis-electron.pdf

对于这种“考古”方式对于漏洞挖掘思路理解是非常有帮助的？！

---

本文由 Seebug Paper 发布，如需转载请注明来源。本文地址：https://paper.seebug.org/1915/

← CVE-2022-0540 Atlassian JIR...

r

知道创宇404实验室

知道创宇404实验室，是国内黑客文化深厚的网络安全公司知道创宇最神秘和核心的部门，长期致力于Web 、IoT 、工控、区块链等领域内安全漏洞挖掘、攻防技术的研究工作，团队曾多次向国内外多家知名厂商如微软、苹果、Adobe 、腾讯、阿里、百度等提交漏洞研究成果，并协助修复安全漏洞，多次获得相关致谢，在业内享有极高的声誉。

阅读更多有关该作者的文章