作者：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實驗室 寫的詳細分析：http://www.bjnorthway.com/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實驗室 帶來的分析：http://www.bjnorthway.com/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漏洞http://www.bjnorthway.com/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 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1915/