作者：360 Core Security
博客：http://blogs.#/post/PoisonNeedles_CVE-2018-15982.html?from=timeline&isappinstalled=0
概述
近年來，烏克蘭和俄羅斯兩國之間圍繞領土問題的爭執不斷，發生了克里米亞半島問題、天然氣爭端、烏克蘭東部危機等事件。伴隨著兩國危機事件愈演愈烈之時，在網絡空間中發生的安全事件可能比現實更加激烈。2015年圣誕節期間烏克蘭國家電力部門受到了APT組織的猛烈攻擊，使烏克蘭西部的 140 萬名居民在嚴寒中遭遇了大停電的煎熬，城市陷入恐慌損失慘重，而相應的俄羅斯所遭受的APT攻擊，外界卻極少有披露。
2018年11月25日，烏俄兩國又突發了“刻赤海峽”事件，烏克蘭的數艘海軍軍艦在向刻赤海峽航行期間，與俄羅斯海軍發生了激烈沖突，引發了全世界的高度關注。在2018年11月29日，“刻赤海峽”事件后稍晚時間，360高級威脅應對團隊就在全球范圍內第一時間發現了一起針對俄羅斯的APT攻擊行動。值得注意的是此次攻擊相關樣本來源于烏克蘭，攻擊目標則指向俄羅斯總統辦公室所屬的醫療機構。攻擊者精心準備了一份俄文內容的員工問卷文檔，該文檔使用了最新的Flash 0day漏洞cve-2018-15982和帶有自毀功能的專屬木馬程序進行攻擊，種種技術細節表明該APT組織不惜代價要攻下目標，但同時又十分小心謹慎。在發現攻擊后，我們第一時間將0day漏洞的細節報告了Adobe官方，Adobe官方及時響應后在12月5日加急發布了新的Flash 32.0.0.101版本修復了此次的0day漏洞。
按照被攻擊醫療機構的網站（http://www.p2f.ru） 介紹，該醫療機構成立于1965年，創始人是俄羅斯聯邦總統辦公室，是專門為俄羅斯聯邦最高行政、立法、司法當局的工作人員、科學家和藝術家提供服務的專業醫療機構。由于這次攻擊屬于360在全球范圍內的首次發現，結合被攻擊目標醫療機構的職能特色，我們將此次APT攻擊命名為“毒針”行動。目前我們還無法確定攻擊者的動機和身份，但該醫療機構的特殊背景和服務的敏感人群，使此次攻擊表現出了明確的定向性，同時攻擊發生在“刻赤海峽”危機的敏感時段，也為攻擊帶上了一些未知的政治意圖。
攻擊過程分析
攻擊者通過投遞rar壓縮包發起攻擊，打開壓縮包內的誘餌文檔就會中招。完整攻擊流程如下：
當受害者打開員工問卷文檔后，將會播放Flash 0day文件。
觸發漏洞后， winrar解壓程序將會操作壓縮包內文件，執行最終的PE荷載backup.exe。
0day漏洞分析
通過分析我們發現此次的CVE-2018-15982 0day漏洞是flash包com.adobe.tvsdk.mediacore.metadata中的一個UAF漏洞。Metadata類的setObject在將String類型（屬于RCObject）的對象保存到Metadata類對象的keySet成員時，沒有使用DRCWB（Deferred Reference Counted, with Write Barrier）。攻擊者利用這一點，通過強制GC獲得一個垂懸指針，在此基礎上通過多次UAF進行多次類型混淆，隨后借助兩個自定義類的交互操作實現任意地址讀寫，在此基礎上泄露ByteArray的虛表指針，從而繞過ASLR，最后借助HackingTeam泄露代碼中的方式繞過DEP/CFG，執行shellcode。
漏洞成因分析
在漏洞的觸發過程，flash中Metadata的實例化對象地址，如下圖所示。
循環調用Metadata的setObject方法后，Metadata對象的keySet成員，如下圖所示。
keySet成員的部分值，如下圖所示。
強制垃圾回收后keySet成員被釋放的內存部分，如下圖所示。
在new Class5重用內存后，將導致類型混淆。如下圖所示。
后續攻擊者還通過判斷String對象的length屬性是否為24來確定漏洞利用是否成功。（如果利用成功會造成類型混淆，此時通過獲取String對象的length屬性實際為獲取Class5的第一個成員變量的值24）。
通過進一步反編譯深入分析，我們可以發現Metadata類的setObject對應的Native函數如下圖所示，實際功能存在于setObject_impl里。
在Object_impl里，會直接將傳入的鍵（String對象）保存到Metadata的keySet成員里。
Buffer結構體定義如下（keySet成員的結構體有一定差異）。
add_keySet中保存傳入的鍵(String對象)，如下代碼所示。
這個時候垃圾回收機制認為傳入的鍵未被引用，從而回收相應內存，然而Metadata對象的keySet成員中仍保留著被回收的內存的指針，后續通過new Class5來重用被回收的內存，造成UAF漏洞。
漏洞利用分析
在實際的攻擊過程中，利用代碼首先申請0x1000個String對象，然后立即釋放其中的一半，從而造成大量String對象的內存空洞，為后面的利用做準備。
隨后，利用代碼定義了一個Metadata對象，借助setObject方法將key-value對保存到該對象中，Metadata對象的keySet成員保存著一個指向一片包含所有key(以String形式存儲)的內存區域的指針。緊接著強制觸發GC，由于keySet成員沒有使用DRCWB，keySet成員內保存著一個指向上述內存區域的垂懸指針，隨后讀取keySet到arr_key數組，供后面使用。
得到垂懸指針后，利用代碼立即申請0x100個Class5類對象保存到vec5（vec5是一個向量對象），由于Class5類對象的內存大小和String對象的內存大小一致（32位下均為0x30字節），且相關對象分配在同一個堆內，根據mmgc內存分配算法，會有Class5對象占據之前被釋放的String對象的內存空間。
其中Class5對象定義如下，可以看到該Class5有2個uint類型的成員變量，分別初始化為0x18和2200(0x898)。
隨后遍歷key_arr數組，找到其中長度變為為0x18的字符串對象（在內存中，String對象的length字段和Class5的m_1成員重合），在此基礎上判斷當前位于32位還是64位環境，據此進入不同的利用分支。
接上圖，可以看到：在找到被Class5對象占用的String索引后，利用代碼將arr_key的相關屬性清零，這使得arr_key數組內元素（包括已占位Class5對象）的引用計數減少變為0，在MMgc中，對象在引用計數減為0后會立刻進入ZCT（zero count table）。隨后利用代碼強制觸發GC，把ZCT中的內存回收，進入后續利用流程。下面我們主要分析32位環境下的利用流程。
下面我們主要分析32位環境下的利用流程，在32位分支下，在釋放了占位的Class5對象后，利用代碼立即申請256個Class3對象并保存到另一個向量對象vec3中，此過程會重用之前被釋放的某個（或若干）Class5對象的內存空間。
其中Class3對象的定義如下，它和Class5非常相似，兩者在內存中都占用0x30字節。
可以看到Class3有一個m_ba成員和一個m_Class1成員，m_ba被初始化為一個ByteArray對象，m_Class1被初始化為一個Class1對象，Class1對象定義如下：
Class3對象占位完成后，利用代碼立即遍歷vec5尋找一個被Class3對象占用內存的原Class5對象。找到后，保存該Class5對象的索引到this.index_1，并保存該對象（已經變為Class3對象）的m_Class1成員到this.ori_cls1_addr，供后續恢復使用。
兩輪UAF之后，利用代碼緊接著利用上述保存的index_1索引，借助vec5[index_1]去修改被重用的Class3對象的m_Class1成員。隨后立即遍歷vec3去尋找被修改的Class3對象，將該對象在vec3中的索引保存到this.index_2。
到目前為止，利用代碼已經得到兩個可以操縱同一個對象的vector(vec5和vec3)，以及該對象在各自vec中的索引(index_1和index_2)。接下來利用代碼將在此基礎上構造任意地址讀寫原語。
我們來看一下32位下任意地址讀寫原語的實現，從下圖可以看到，借助兩個混淆的Class對象，可以實現任意地址讀寫原語，相關代碼在上圖和下圖的注釋中已經寫得很清楚，此處不再過多描述。關于減去0x10的偏移的說明，可以參考我們之前對cve-2018-5002漏洞的分析文章。
64位下的任意地址讀寫原語和32位下大同小異，只不過64位下將與Class5混淆的類對象換成了Class2和Class4。此外還構造了一個Class0用于64位下的地址讀取。
以下是這三個類的定義。
以下是64位下的任意地址讀寫原語，64位下的讀寫原語一次只能讀寫32位，所以對一個64位地址需要分兩次讀寫。
利用代碼借助任意地址讀寫構造了一系列功能函數，并借助這些功能函數最終讀取kernel32.dll的VirtualProtect函數地址，供后面Bypass DEP使用。
利用最終采用與HackingTeam完全一致的手法來Bypass DEP/CFG。由于相關過程在網上已有描述，此處不再過多解釋。32和64位下的shellcode分別放在的Class6和Class7兩個類內， shellcode最終調用cmd啟動WINRAR相關進程，相關命令行參數如下：
漏洞補丁分析
Adobe官方在12月5日發布的Flash 32.0.0.101版本修復了此次的0day漏洞，我們通過動態分析發現該次漏洞補丁是用一個Array對象來存儲所有的鍵，而不是用類似Buffer結構體來存儲鍵，從而消除引用的問題。
1、某次Metadata實例化對象如下圖所示，地址為0x7409540。
2、可以看到Metadata對象的偏移0x1C處不再是類似Buffer結構體的布局，而是一個Array對象，通過Array對象來存儲鍵值則不會有之前的問題。
3、循環調用setObject設置完鍵值后keySet中的值如下所示。
4、強制垃圾回收發現保存的ketSet中的指針仍指向有效地字符串，說明強制垃圾回收并沒有回收鍵值對象。
最終荷載分析
PE荷載backup.exe將自己偽裝成了NVIDIA顯卡控制臺程序，并擁有詳細文件說明和版本號。
文件使用已被吊銷的證書進行了數字簽名。
PE荷載backup.exe啟動后將在本地用戶的程序數據目錄釋放一個NVIDIAControlPanel.exe。該文件和backup.exe文件擁有同樣的文件信息和數字簽名，但文件大小不同。
經過進一步的分析，我們發現PE荷載是一個經過VMP強加密的后門程序，通過解密還原，我們發現主程序主要功能為創建一個窗口消息循環，有8個主要功能線程，其主要功能如下：
線程功能：
主消息循環功能：
線程功能分析
0 分析對抗線程
檢驗程序自身的名稱是否符合哈希命名規則,如符合則設置自毀標志。
1 喚醒線程
監控用戶活動情況，如果用戶有鍵盤鼠標活動則發送0x401消息給主窗口程序，喚醒創建注冊計劃任務線程。
2 休眠線程
取當前TickCount 進行比較，低位小于100則發送 WM_COPYDATA指令 主窗口循環在接收這一指令后，會休眠一定時間
3 定時自毀線程
解密程序中的時間字符串與當前系統時間進行比較，如果當前系統時間較大，則設置標志位，并向主窗口發送0x464消息（執行自毀）。
4 通信線程
獲取機器信息 包括CPU型號,內存使用情況,硬盤使用情況,系統版本,系統語言,時區 用戶名,SID,安裝程序列表等信息。
向 188.241.58.68 發送POST
連接成功時,繼續向服務器發送數據包
符合條件時,進入RunPayload函數（實際并未捕獲到符合條件的情況）
RunPayload函數
LoadPE
RunShellCode
5 注冊自啟動線程
1、首先拿到線程6中保存的AppData\Local目錄下的NVIDIAControlPanel文件路徑，使用該路徑或者該路徑的短路徑與當前文件模塊路徑判斷是否相同。
2、隨后嘗試打開注冊表HKEY_CURRENT_USER下SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\StartupFolder。
3、查詢當前注冊表路徑下NVIDIAControlPanel鍵值是否存在，如果不存在或者為禁用狀態則設置鍵值為啟用的鍵值02,00,00,00,00,00,00,00,00,00,00,00。
6 注冊計劃任務線程
檢查自身是否運行在System進程
如果運行在system進程, 則彈出Aborting消息, 退出進程,并清理環境
并不斷向 Windows Update窗口投遞退出消息
三種文件拷貝方式
其使用了三種不同的方式去拷貝自身文件：
- 在監測到殺軟相關進程之后, 會使用Bits_IBackgroundCopyManager方式進行自拷貝
- 如果沒有相關殺軟進程, 會使用iFileOperation 方式進行自拷貝
- 如果在以上工作方式之行結束, 仍未有文件拷貝到目標目錄, 則執行釋放BAT方式進行自拷貝
Bits_IBackgroundCopyManager
(5ce34c0d-0dc9-4c1f-897c-daa1b78cee7c)
iFileOperation
{3ad05575-8857-4850-9277-11b85bdb8e09}
批處理文件釋放
創建批處理文件，拷貝自身來釋放文件。
固定釋放常駐后門: F951362DDCC37337A70571D6EAE8F122
檢測殺軟
檢測的殺軟包括F-Secure, Panda, ESET, Avira, Bitdefender, Norton, Kaspersky 通過查找名稱和特定驅動文件實現
檢測的殺軟之后會執行自毀流程
添加計劃任務
7 自毀線程
判斷系統版本后分別使用ITask和ITaskService 停止NVIDIAControlPanel這個計劃任務
Win7以前采用ITask接口：
Win7和Win7以后采用ITaskService接口：
在完成后清理文件。
附錄IOC
MD5：
92b1c50c3ddf8289e85cbb7f8eead077
1cbc626abbe10a4fae6abf0f405c35e2
2abb76d71fb1b43173589f56e461011b
C&C：
188.241.58.68
本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/753/
暫無評論