作者：且聽安全
原文鏈接：https://mp.weixin.qq.com/s/q0lbegDjLViLI48N6RjGVw
接上文：
第一部分：樣本分析
分析完網上流傳的樣本后，我準備嘗試替換cab文件中的文件后復現漏洞。安裝的office軟件版本：Microsoft Word 2016 （16.0.4266.1003）:
Windows的版本：Windows10 1909 （build 18363.1734）。我們首先在虛擬機上用原始的docx進行復現測試，先修改hosts文件，將域名解析為127.0.0.1：
將ministry.cab和side.html預先存放在一個目錄下（目錄名根據前期的樣本分析，設置為e8c76295a5f9acb7），并在上層目錄用python開一個http服務，服務端口為80：
然后嘗試打開惡意docx文件，可以看到http服務器上有對應像下載請求：
可以使用Process Monitor來看一下word在打開惡意樣本的時候到底做了什么，啟動前先設個過濾器：
重新打開docx，Process Monitor會記錄word（即winword.exe）的所有操作，可以看到word將side.html存放在臨時目錄下，并改名為side[1].htm
繼續往下翻，還可以看到word將ministry.cab存在了另一個臨時目錄下，并改名為ministry[1].cab，但是用資源管理器查看時發現文件已經被刪除了。
繼續往下翻，還可以看到word又在Temp目錄下創建了文件championship.inf
而后面則是使用control.exe 執行 .cpl:../../../AppData/Local/Temp/championship.inf，可以合理推測惡意軟件已被成功執行（惡意軟件的進一步分析已超出本文的范圍）：
下一步我們準備替換ministry.cab文件中的文件，看能否實際執行成功，所以我們要做的就是重新創建一個cab包，就像這樣：
將新的cab替換原來的文件后，再次打開docx，結果并沒有預期那樣釋放我們提供的messagebox.dll（通過瀏覽Process Monitor監控，沒有看到創建文件操作），這一點比較奇怪（后面在漏洞成因分析中，通過逆向urlmon.dll就能發現原因了）。
于是我將自定義的dll重命名為championship.inf（跟原始樣本一樣），再試一次：
這次應該是成功釋放了，不過釋放的目錄不一樣，沒有直接存放在Temp目錄下，而是在一個隨機文件名的臨時目錄下（這樣的話control.exe就沒辦法找到championship.inf）：
看來只能對比新舊兩個ministry.cab有什么區別了：
通過對比發現原始的ministry.cab中文件的名稱前有../，這也就解釋了為什么原始的文件會釋放在Temp目錄下，而我們自己做的卻沒有。所以我們得重新創建一個cab，而其中的文件名也是../championship.inf。
為了方便，我們可以先用makecab打包一個xxxchampionship.inf，然后再用二進制編輯軟件將文件名的前3個字節其修改為../，再次嘗試果然也成功釋放到了Temp目錄下，但是似乎一直沒有被執行，通過仔細查看Process Monitor中的結果，我們發現了下面的一項：
這個championship.inf居然直接被刪除了，而對比原始樣本，在CloseFile前沒有這一項：
這個問題困擾了我一段時間，但是目前我還不想逆向整個漏洞的成因和觸發流程。現在整個漏洞利用鏈條，我們修改過的僅僅是這個cab文件，所以問題肯定就在這個文件上面，而cab文件的頭又非常簡單，通過幾次嘗試，終于找到了問題所在：就是CFFILE結構中的cbFile字段：
當我們將該長度改一個比正常值更大的值，則釋放的championship.inf文件將不再被刪除，惡意代碼將被執行：
事實上，當cbFile的大小超出cab包的實際大小時，將發生訪問異常，導致championship.inf沒有被正常清除，使惡意代碼得以執行，詳細分析見下一章的漏洞成因分析。
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1795/
暫無評論