綜述
近期，安全社區通過VirusTotal發現一個通過Office遠程加載特性訪問HTML頁面進而利用ms-msdt協議在Word文檔中執行惡意PowerShell的0day漏洞利用文檔。其實該漏洞早在4月12日就已經被相關安全人員通過VT發現並提交給微軟，其利用上和去年的CVE-2021-40444有很多相似之處，通過OLE的方式遠程拉取一個惡意HTML，該HTML中通過msdt協議繞過了Office自帶的保護視圖。後續通過分析發現微軟實際上之前已經嘗試修復該問題，但是依舊存在rtf文件格式的繞過，最後通過msdt協議中的一處powershell注入導致最終的代碼執行。
漏洞分析
樣本通過構造一個ole對象遠程拉取惡意的html文件，這裡的加載方式和CVE-2021-40444類似。
Html文件如下所示，其中使用了ms-msdt協議，該協議是Microsoft Support Diagnostics Tool 的縮寫，它是一種實用程序，用於排除故障並收集診斷數據以支持專業人員分析以解決問題，其可以調用本地腳本，而不觸發office的保護視圖，從而導致代碼執行，如下所示樣本執行的代碼通過base64編碼。
編碼的數據如下所示，這裡猜測其中實際執行的exe應該是通過某種方式部署到了目標機器中（目前未知）。
這裡構造poc就很簡單了，替換換成模板注入的html即可，這裡確保你的遠端exp 存在這個路徑下http://127.0.0.1:8080/www/RDF842l.html
如下所示，確保RDF842l.html保存路徑如下所示：
打開對應的52945af1d.docx，即可觸發代碼執行，這裡的測試環境是office 2019
可以看到在觸發漏洞的時候，word會通過註冊表選項查找對應的md-msdt這個協議，用於處理腳本中的ms-msdt後續的字段可以看到最終其實找到的就是執行代碼的msdt.exe這個程序。
當你把office升級到大版本2205後，漏洞將不再觸發，需要注意目前只有2019/2021提供自動更新功能。
通過該功能可更新到大版本2205，該版本不受影響。
如下所示，可以看到完全不會觸發協議的訪問，因為其中利用的特殊的 Office 遠程 OLE 對象自動加載方式已經被作為非安全問題修復（沒有CVE編號）。但是攻擊者依然可以使用 rtf 格式樣本來實現自動觸發漏洞。
其構造方式只需要將之前的docx文檔按rtf另存一份即可。
分析發現計算器是由sdiagnhost.exe這個程序啟動的。
分析sdiagnhost.exe發現其是通過CScriptedDiagNativeHost::RunScript函數來啟動的calc。
這裡通過函數名可以猜測是用於調用本地的腳本，調試發現其參數傳遞了一個ps1腳本：
C:\Windows\diagnostics\system\PCW\TS_ProgramCompatibilityWizard.ps1
對應的參數就是構造的exp中的IT_BrowseForFile = /../../$(calc).exe，這是最簡的exp，在sdiagnhost.exe中沒有任何相關的參數過濾操作。
來看TS_ProgramCompatibilityWizard.ps1腳本可以看到通過注釋發現其功能為」 如果在這些位置沒有找到快捷方式，我們將轉到瀏覽文件屏幕」，獲取的IT_BrowseForFile保存在selectedProgram，並通過Test-Selection校驗。
Test-Selection邏輯如下，首先判斷其路徑是否為空，之後依次為test-path -literalpath $appPath及判斷是否以exe/msi後綴結尾，這也就是為什麼我們exp中最後必須是.exe，.msi也是可以的。
這裡來看test-path -literalpath $appPath，可以看到其用於判斷一個路徑，如下所示這裡/../../也是合法的，因此exp中需要構造至少/../../，否則你就需要提供一個真實合法的路徑。
可以看到我們傳入的參數實際上看着是有判斷$()注入情況的。
最終應該是以下位置的代碼導致代碼執行，這裡$appName/$selectedProgram都來自於攻擊者的輸入，而這兩個參數通過閱讀代碼可知，$selectedProgram是沒有經過$檢測的，而$appName有，詳細我們可以通過修改腳本日誌輸出來看看具體的問題。
通過查詢也可知，這裡疑似最終代碼調用的cmdlet並不能直接通過powershell跑，其只能通過漏洞觸發的路徑有msdt.exe – > sdiagnhost.exe->TS_ProgramCompatibilityWizard.ps1 來調用。
當我們需要修改TS_ProgramCompatibilityWizard.ps1腳本進行日誌輸出的時候發現，無法修改這個文件，這裡可以通過修改其對應訪問策略來使得其他用戶也能修改該文件，從而有助於我們的調試。
首先將selectedProgram獲取的值輸出，並在selectedProgram經過Test-Selection檢測後同樣輸出，看是否有什麼變化。
之後經過while循環後的selectedProgram輸出，看有什麼變化，同樣將關鍵參數appName輸出，看看這裡的Replace是否真正起到了過濾的作用。
在關鍵代碼執行前輸出appName/selectedProgram這兩個參數，並通過注釋掉Update-DiagRootCause這行代碼來確定真正觸發代碼執行的位置是否是這裡。
通過測試後發現Update-DiagRootCause這行代碼注釋後，漏洞無法觸發，即該調用導致了最終的代碼執行，而其傳入的參數日誌輸出如下所示，可以看到selectedProgram全程都是/../../$(calc).exe，沒有經過過濾，而appName經過replace之後的值為$(calc)，並不是我們期待的`$(calc)，那這裡到底是appName/selectedProgram導致了代碼執行？
我們嘗試對這個兩個變量進行控制。
如下所示可以看到運行後，二者只要用一個正常，漏洞都能觸發，即導致漏洞的是$appName /$selectedProgram這兩個參數，由於對其過濾不嚴格，從而導致了powershell的代碼注入。
如下所示可以看到gui下的攻擊入口其實就是下圖的位置
這裡將其替換為/../../$(calc).exe
將直接代碼執行
該樣本通過ole對象拉取惡意html的動作會導致office落地文檔直接被查殺。
相關yara規則
文檔打開後觸發下載的html yara規則如下所示，其本身會出現在流量中。
總結
奇安信紅雨滴團隊在此提醒廣大用戶，切勿打開社交媒體分享的來歷不明的鏈接，不點擊執行未知來源的郵件附件，不運行誇張標題的未知文件，不安裝非正規途徑來源的APP。做到及時備份重要文件，更新安裝補丁。
若需運行，安裝來歷不明的應用，可先通過奇安信威脅情報文件深度分析平台（https://sandbox.ti.qianxin.com/sandbox/page）進行判別。目前已支持包括Windows、安卓平台在內的多種格式文件深度分析。
目前，基於奇安信威脅情報中心的威脅情報數據的全線產品，包括奇安信威脅情報平台（TIP）、奇安信天狗漏洞攻擊防護系統、天擎、天眼高級威脅檢測系統、奇安信NGSOC、奇安信態勢感知等，都已經支持對此類攻擊的精確檢測。
留言列表