By HireHackking in HACKER
· 2 views
漏洞鏈攻擊是從以下誘餌開始:
分析時，研究人員觀察到一個有趣的Microsoft Word文檔(.docx文件)於2023年7月3日首次提交給VirusTotal，名為Overview_of_UWCs_UkraineInNATO_campaign.docx。
該活動被社區歸因於Storm-0978(也被稱為RomCom組織，因為他們使用了RomCom後門)。
惡意Word文檔誘餌
此文檔託管在以下URL：
hxxps://www.ukrainianworldcongress[.]info/sites/default/files/document/forms/2023/Overview_of_UWCs_UkraineInNATO_campaign.docx上面的鏈接表明該文檔很可能是通過電子郵件傳播的，電子郵件文本包含指向.docx文件的鏈接。文件的創建日期和域名ukrainianworldcongress的註冊日期都是2023年6月26日。這個時間點表明，這是一個基於電子郵件的活動，其中包含.docx文件的鏈接。
當該文件最初提交給VirusTotal時，62個殺毒軟件中有27個將其識別為惡意文件。
CVE-2023-36584利用的技術分析微軟Office文檔一直是攻擊者傳播惡意軟件的常用攻擊手段。為了應對這一威脅，微軟實施了mow安全，限制Office文檔中的各種功能來自不受信任的位置。
Windows將這些文件識別為高風險文件。帶有mow標記的文件會生成一個SmartScreen提示，表明它有潛在的危險。當Word文檔未標記為mow時，就會被攻擊者利用，導致禁用Protected View。
為了理解CVE-2023-36884是如何被特定的誘餌利用的，我們應該首先了解Microsoft Word對Open XML文件格式的實現過程，在本例中是針對MS-DOCX (.docx)文件。
MS-DOCX文件是一個壓縮的ZIP歸檔文件，其中包含用於顯示Word文檔的多個規範文件。其中之一是位於word/document.xml的XML文件。這是MS-DOCX文件的核心XML組件，它包含文檔的文本和格式。
在Microsoft Word中查看MS-DOCX文件時，文檔的大部分內容都是通過Word /document.xml導入的。
在.docx誘餌中，word/document.xml使用名為altChunk的導入外部內容元素導入內容，如下圖所示。
這個altChunk元素可以導入使用另一種格式的內容，比如富文本格式(RTF)，來自.docx文件的word/document.xml有一個altChunk元素，它使用標識符AltChunkId5指示與外部內容的關係。這個標識符在word/_rels/document.xml.rels的關係文件中被定義。
上圖中顯示的document.xml.rels代碼片段將導入的目標標識為位於word/afchunk.rtf的文件。
RTF文件afchunk.rtf包含兩個惡意的OLE (Object Linking and Embedding)對象。第一個OLE對象使用帶有objautlink RTF控製字的OLE自動鏈接類型，在objautlink控製字之後，一個objupdate控製字強制對像在顯示之前進行更新，如下圖所示。
對像類被定義為Word.Document.8，其數據在其標頭中包含LinkedObject結構，後跟表示十六進製字符的ASCII文本。
我們使用Didier Steven的rtfdump.py工具進一步檢查afchunk.rtf。下圖顯示了前面所示的objautlink片段的十六進制(hex)輸出，這個輸出更清楚地顯示了LinkedObject結構。
第一個惡意OLE對象的rtfdump.py輸出
此十六進制轉儲顯示\\104.234.239[.]26\share1\MSHTML_C7\file001.url，一個使用服務器消息塊（SMB）協議的惡意url。
使用rtfdump.py查看afchunk.rtf，我們發現另一個使用xmlfile類的惡意OLE對象，其標頭包含EmbeddedObject結構。嵌入的對像是一個複合文檔，其中包含一個URLMoniker，它從URL加載XML文件hxxp://74.50.94[.]156/MSHTML_C7/start.xml，如下圖中的藍色標註。
第二個惡意OLE對象的rtfdump.py輸出
漏洞利用鏈的第一階段對該漏洞利用鏈的初步研究得出了一個流程圖，該流程圖由@zcracga創建，並於2023年7月12日由@r00tbsd共享。該流程圖有助於可視化通過漏洞利用鏈工作的不同階段。
漏洞利用鏈流程圖
我們最初關注的域是afchunk.rtf中惡意OLE對象的兩個URL。如前所述，這些OLE對像從以下URL請求內容：
\\104.234.239[.]26\share1\MSHTML_C7\file001.url
hxxp://74.50.94[.]156/MSHTML_C7/start.xml當Windows客戶端連接到SMB服務器時，該客戶端會發送Windows NT LAN Manager（NTLM）憑據進行身份驗證。因此，當受害者主機訪問位於\\104.234.239[.]26\share1\MSHTML_C7\file001.URL的URL時，它會將受害者的NTLM憑據及其主機名和用戶名洩漏給攻擊者控制的SMB服務器。收集到的信息稍後將用於攻擊鏈。
下圖顯示了嵌入file001.url中的HTML代碼。
file001.url片段
通過檢查file001.url，UName變量包含受害者的用戶名。這是攻擊者控制的SMB服務器從受害者洩露的NTLM憑據中收集的用戶名。如果上圖顯示的變量d不為空，則漏洞利用鏈將用戶名與攻擊者傳遞的值連接起來，該值用於創建名為2222.CHM的CHM文件的路徑，該文件包含在名為file001.zip的文件中。
在攻擊鏈的這一階段，2222.chm不存在，或者它可能是攻擊者使用的其他攻擊的一部分。 file001.url的進一步行為將在後面解釋，因為它與2222.chm密切相關。
afchunk.rtf中的第二個惡意OLE對象來自hxxp://74.50.94[.]156/MSHTML_C7/start.xml。此start.xml文件包含一個iframe，用於從同一服務器和目錄路徑加載另一個名為RFile.asp的文件。
start.xml中引用RFile.asp的iframe片段
RFile.asp負責在服務器上加載另一個文件，該文件的攻擊特定路徑定義為：
file[:]//104.234.239[.]26/share1/MSHTML_C7/1/__file001.htm?d=__該路徑由受害者的
RFile.asp中的代碼段
濫用Windows搜索處理程序file001.htm的核心行為是執行JavaScript，如下圖中的代碼片段所示。
file001.htm片段
file001.htm中的JavaScript使用iframes來加載幾個文件。它首先加載一個保存的搜索文件，該文件的文件名由受害者的IP地址和以字符串file001.search-ms結尾的五位標識符組成。我們將把這個文件稱為其文件名file001.search-ms的最後一部分。
接下來是三個HTTP請求，在它們的url中使用字符串.zip_k*。除了執行計時或無操作（no-op）操作外，此行為沒有明顯的價值。
最後，MSHTML重新加載file001。 Search-ms然後加載redir_obj.htm。
這些請求的順序很明顯，因為預期的目的並不明顯。根據相關網絡流量示例中的時間戳，我們推測通過服務器端操作實現了這種事件順序的繞過，其中對.zip_k*文件的請求被用作延遲機制。下圖顯示了在Wireshark中過濾流量的數據包捕獲(pcap)，突出顯示了一個HTTP GET請求與其HTTP響應之間的兩秒延遲。
使用zip_k.asp延遲響應請求
在檢查文件redir_obj.htm時，我們發現瞭如下圖所示的代碼片段。這段代碼從本地路徑加載一個文件，該文件使用在初始SMB連接期間捕獲的洩漏的主機名和用戶名分別作為CompName和UName變量，其用於打開文件file001.zip中名為1111.htm的HTML文件。
來自redir_obj.htm的片段
重新創建Windows搜索處理程序文件我們使用Windows文件資源管理器創建一個空白保存的搜索文件，文件擴展名為.search-ms，以控制包含2222的ZIP文件的位置。提取CHM並說明這個漏洞利用鍊是如何工作的。我們在File Explorer中啟動搜索並保存結果，這創建了一個.search-ms文件。這個保存的搜索文件是一個空白模板，可以重現這個漏洞利用鏈中使用的搜索處理程序文件行為。
Windows系統文件Windows. storage .search .dll處理.search-ms文件。為了成功地將ZIP文件解壓縮到redir_obj.htm文件中指定的目錄中(由圖11中所示的JavaScript iframe加載)，需要進行一些更改。
首先，include元素必須包含一個本地路徑作為它的網絡路徑，並使用FILE_ATTRIBUTE_NORMAL，實現為變量attributes='128'。
基本.search ms文件，已更改為觸發ZIP提取
接下來，autoListFlags屬性必須打開第二個最低有效位，如下圖所示。這將產生一個完整的搜索，其中還包括任何ZIP存檔的內容。
在Windows.Storage.Search.dll中進行.search-ms處理的示例
此時處理.search ms文件將在目標計算機上按以下路徑創建一個目錄：
C:\Users\[USERNAME]\AppData\Local\Temp\[Temp1_zip_filename]
ZIP文件的內容隨後被提取到該目錄中。
search-ms根據早期SMB洩露的主機信息處理ZIP文件的放置和內容提取。
結果證實了從ZIP文件中提取的兩個文件：1111.htm和2222.chm。
在利用Office中以前的RCE漏洞CVE-2021-40444時，也觀察到了類似的行為。在該攻擊中，攻擊者會利用Microsoft Compressed Archive（CAB）路徑遍歷提取漏洞來實現類似的目標：將HTML文件提取到計算機上的可預測路徑。
在討論1111.htm和2222.chm文件之前，我們首先應該了解Windows安全區域。
Windows安全區域和其他障礙Windows安全區域也被稱為Internet Explorer安全區域或URL安全區域，Windows安全區域是微軟用來確定來自不同來源文件的權限機制。通常，從internet檢索的文件被標識為來自“internet Zone”，並標記為受限權限的mow。
此數據存儲在名為Zone.Identifier的文件的備用數據流（ADS）中，用於指示文件的安全區域。來自“Internet Zone”的文件的ZoneId值為3(安全區域3)。
為了使攻擊鏈的其餘部分成功，1111.htm和2222.chm文件的ZoneId值都必須在其Zone.Identifier ADS（安全區域1）中標識為1。然而，這是一個障礙，因為從遠程路徑下載並由.search-ms提取的ZIP內容的ZoneId值為3，並且該內容會自動標記為MotW。
為了成功利用，還必須克服另外兩個障礙:
障礙1：當Windows Search使用.Search ms完成時，它會刪除[Temp1_zip_filename]目錄。這將生成一個競爭條件，以加載臨時目錄中的文件。
障礙2：默認情況下，Windows不會搜索CHM文件的內容。 2222.chm文件是此漏洞利用鏈的一部分，但它不會使用Windows搜索的默認設置從ZIP存檔中提取。
使用CVE-2023-36584繞過MotW在使用CVE-2023-36884對這個漏洞鏈進行分析期間，研究人員發現了一個漏洞利用途徑，微軟將其命名為CVE-2023-36584。
Windows Search在搜索期間遍歷ZIP存檔中的所有文件。 Windows Search檢查每個文件的文件擴展名，以確定其內容是否也需要搜索。如果是，Windows Search將該文件寫入臨時目錄，並將mow添加到其中。
這個實現生成了一個固有的競爭條件。在將解壓縮文件寫入磁盤和用mow標記它之間有很短的時間窗口。如果我們在這個窗口中延遲Windows搜索，我們可以解決競爭條件並最終繞過mow。
先前利用CVE-2022-41049的技術通過向ZIP存檔中的文件添加只讀屬性來繞過motw，這避免了對區域的修改。這避免了對Zone.Identifier ADS的修改，並阻止了提取的文件接收MotW。這項技術啟發了我們，並使我們發現繞過MotW。
技術1：服務器端ZIP交換服務器端操作使我們能夠解決這些問題，我們發現了一個從檢查時間到使用時間(TOCTOU)的漏洞，當從遠程服務器下載ZIP歸檔文件時，可以利用該漏洞。
Windows使用系統文件zipfldr.dll來提取ZIP存檔的內容。這個Windows DLL文件讀取ZIP文件的標頭並將數據緩存在內存中，同時ZIP存檔的內容被提取並保存到磁盤。 Zipfldr.dll公開了一個API，該API可用於通過在ZIP存檔中指定文件索引來提取文件。
讀取文件標頭後，在使用zipfldr.dll對其進行解壓縮之前，我們可以將遠程服務器上的ZIP文件替換為包含不同名稱文件的ZIP文件，從而導致MotW無法寫入。
這種技術之所以有效，是因為urlmon.dll使用文件路徑來寫入最初從緩存在內存中的ZIP標頭讀取的MotW，以便繞過將MotW寫入文件。
該技術解決了前面提到的關於利用CVE-2023-36884的兩個障礙。成功解壓縮了.chm文件，否則將無法解壓縮，並且這些文件不會立即刪除。
下圖顯示了一個Process Monitor（procmon）視圖，說明創建名為2222.txt的替代文件的嘗試失敗。此條件允許以前保存的2222.chm避免MotW。
使用TOCTOU漏洞繞過mow
我們無法確認這就是攻擊者在原始漏洞利用鏈中使用的確切技術。但是，VirusTotal對初始.docx誘惑的沙箱分析的行為日誌顯示，創建了一個名為1111.txt的文件，表明可能有一個鏡像1111.htm的替代文件名。
技術2：服務器端延遲除了第一種技術外，我們還發現了另外兩種可以顯著延遲mow編寫的技術。此場景防止寫入MotW屬性，並允許從安全區域1中的另一個線程執行文件。
從ZIP存檔中提取文件後，在將MotW添加到Zone.Identifier ADS之前，我們可以從攻擊者控制的SMB服務器引入時間延遲。這是可能的，因為SMB2協議的關閉操作包括關閉請求和結束基於SMB的文件傳輸的關閉響應。
當客戶端接收到來自傳輸文件的所有數據時，它將SMB關閉請求發送回服務器，並等待SMB關閉響應。文件已被傳輸，但傳輸操作尚未完成，直到客戶端收到關閉響應。這是一個同步操作，可以延遲相當長的一段時間。
下圖中的procmon列表顯示了在111.222.11[.]20的SMB服務器在下一次操作之前傳輸了一個名為served.zip的文件後的30秒延遲。這表示關閉請求和關閉響應之間有30秒的延遲。
在這個30秒的窗口中，1111.htm文件是一個沒有MotW的安全區域1文件。在30秒後最終發送了關閉響應後，該過程繼續，並將MotW寫入1111.htm。
mow繞過
技術3：服務器端延遲在從ZIP歸檔文件傳輸大文件時，Windows從遠程共享中讀取文件的一部分，將數據附加到磁盤上的本地文件中，然後從遠程共享中讀取其他部分，直到文件完全寫入磁盤。如果我們在文件末尾附加隨機數據，就可以在Windows將mow添加到文件之前延遲SMB服務器對文件的寫入。該文件在寫入過程中是可用的，因為它是用讀寫dwShareMode打開的。
我們通過在流程中引入10秒延遲來測試這個預設，如下圖所示。
使用延遲閱讀響應的mow
微軟安全更新地址CVE-2023-36884開發此漏洞利用鏈的攻擊者知道SMB文件傳輸期間臨時保存的本地文件的路徑是可預測的。但在微軟2023年8月的安全更新之後，臨時保存的本地文件名中添加了一個通用唯一標識符（UUID），可以使路徑隨機。
微軟2023年8月安全更新後
Recommended Comments