聊下最近的 CVE-2022-30190
2022-6-13 10:43:0 Author: paper.seebug.org(查看原文) 阅读量:48 收藏

作者:[email protected]知道创宇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文件实现命令执行操作,具体分析可以看由[email protected]知道创宇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();

当然整个流程要分析清楚还是相对比较复杂的,详细分析可以参考由 [email protected]知道创宇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

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


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


文章来源: https://paper.seebug.org/1915/
如有侵权请联系:admin#unsafe.sh