建站
咨詢
售后
建站咨詢
新聞中心
前言
為了在IE和Chrome上繞過其沙盒機制完全控制用戶系統(tǒng)，Hacking Team還利用了一個Windows中的內(nèi)核驅動： Adobe Font Driver(atmfd.dll)中存在的一處字體0day漏洞，實現(xiàn)權限提升并繞過沙盒機制。
該0day漏洞可以用于WindowsXP~Windows 8.1系統(tǒng)，X86和X64平臺都受影響，在Hacking Team泄露的源碼中我們發(fā)現(xiàn)了該漏洞的詳細利用代碼。在利用Flash漏洞獲得遠程代碼執(zhí)行權限后，Hacking Team經(jīng)過復雜的內(nèi)核堆操作準備后，加載一個畸形的OTF字體文件，再調(diào)用Atmfd中的相關接口觸發(fā)處理字體文件過程的漏洞，最后獲得任意次數(shù)的任意內(nèi)核地址讀寫權限，接著復制Explorer.exe的token到當前進程，并清除本進程的Job來實現(xiàn)沙盒逃逸。
Chrome 43版本以上默認對沙盒內(nèi)進程使用DisallowWin32k機制關閉了所有win32k相關調(diào)用，因此不受這個漏洞的影響。
下面是該漏洞的具體分析，本文分析來自360Vulcan Team的pgboy：
1. 漏洞分析
通過分析漏洞利用的源碼我們看到，該漏洞在加載字體完成后利用NamedEscape函數(shù)的0x2514命令來觸發(fā)關鍵操作
通過跟蹤NamedEscape我們可以找到存在于atmfd.dll里面漏洞點:
以下是筆者測試機器上atmfd的版本(win7 32bit):
相關觸發(fā)漏洞的callback代碼如下：
F5之后的callback代碼
這個Callback被外層函數(shù)循環(huán)調(diào)用寫入緩存：
我們可以看到，這里參數(shù)a3是一個有符號的16位數(shù)，當a3>0x8000的時候，movsx會將其擴展成0xffff8xxx，因此下面的寫操作就變成了堆上溢，會往給出的緩存地址的前面寫入。這是一個典型的由于符號溢出引發(fā)的堆上溢漏洞。
了解了漏洞的原理后，我們來繼續(xù)分析OTF文件是如何觸發(fā)該問題的，通過調(diào)試結合Adobe的文檔我們可以知道，是在處理OTF文件中CFF表的Charset過程引發(fā)的問題。
我們可以通過T2F Analyzer來觀察這個被加載的OTF字體文件的格式。見下圖：
顯而易見，樣本OTF文件中構造了超長的Charset，然后通過NamedEscape函數(shù)的0x2514命令來獲取Charset的時候，就會觸發(fā)到上面描述的觸發(fā)點，引發(fā)符號溢出。
2.漏洞利用
我們從頭再看一下漏洞利用的流程，整個流程主要分這么幾個部分：
1. 找到內(nèi)核字體對象的地址
由于內(nèi)核字體內(nèi)存的布局無法直接被Ring3代碼探知，利用代碼中使用了一個特殊的技巧來實現(xiàn)獲得內(nèi)核字體對象的地址，在利用代碼中，先加載字體，然后立刻創(chuàng)建一個Bitmap對象，再連續(xù)多次加載這個字體，由于win32k和atmfd中共用了內(nèi)存堆處理函數(shù)，因此會導致Bitmap對象和字體對象是正好相鄰的。
由于Bitmap這類user/gdi對象的實際內(nèi)核地址可以通過映射到Ring3的GdiSharedHandleTable獲得，因此這樣也就可以間接獲得攻擊代碼加載到內(nèi)核的字體對象的范圍。
最后，由于NamedEscape函數(shù)調(diào)用atmfd設備的0x250A號命令可以指定對象的地址，并校驗字體對象的有效性同時將字體對象讀出來，因此攻擊代碼結合Bitmap定位和NamedEscape的0x250a指令，就可以準確獲取字體對象的地址，相關的代碼如下：
2. 觸發(fā)漏洞，實現(xiàn)寫入Bitmap對象
攻擊代碼首先會分配多個0xb000大小的對象，然后找到9個相鄰的Bitmap對象并釋放中間的3個，這樣就在內(nèi)核win32k堆內(nèi)存中留下了0xb000*3= 0x21000大小的空洞，接著攻擊代碼調(diào)用NameDEscape-atmfd的0x2514號命令來讀取超長的Charset，觸發(fā)漏洞。
在這個NamedEscape調(diào)用到atmfd過程中，會分配內(nèi)核對象來復制一份輸入的緩存，這里攻擊代碼將輸入的緩存大小設置為0x20005，由于頁對齊的原因，這里正好可以占住上面我們說到的0x21000大小的空洞內(nèi)存。
這樣在最終符號溢出時，就會寫入到這塊Buffer上面未被釋放的Bitmap對象中，這就通過精確地堆操作完成了將這個符號溢出導致的緩存上溢轉換到對已控制的Bitmap對象的寫入。
這個轉化的流程如下圖所示：
3. 將Bitmap寫入轉換為內(nèi)核任意地址讀寫
在第2步我們講到這里可以通過操作字體接口，將OTF文件的Charset處理的符號溢出漏洞轉換為覆蓋Bitmap對象內(nèi)存的操作，這里我們來看看Bitmap對象在win32k中是如何組織的：它實際是一個 SURFACE對象，結構如下：
其中，Address0其實是指向Bitmap中BitsBuffer的指針，我們可以通過SetBitmapBits函數(shù)來操作BitsBuffer指向的內(nèi)存，可以寫入bitmap對象的SURFACE內(nèi)核結構后，攻擊代碼就可以通過控制Address0來實現(xiàn)任意地址讀寫。
在攻擊代碼中，使用了兩個Bitmap對象，一個Bitmap用來控制讀寫地址，另一個Bitmap2用來進行實際讀寫，我們將Bitmap2作為讀寫地址控制器，將其pBitsBuffer指向實現(xiàn)實際讀寫的Bitmap的pBitsBuffer的地址，這樣就可以實現(xiàn)多次穩(wěn)定的任意地址讀寫。
也就是說，我們通過對Bitmap2進行 SetBitmapBits,設置實際讀寫的 Bitmap的pBitsBuffer為我們想要讀寫的地址，然后就可以通過進行實際讀寫的Bitmap的GetBitmapBits和SetBitmapBits來實現(xiàn)對指定地址的讀寫了，如圖所示：
我們看到，在攻擊代碼中，首先創(chuàng)建了一個假的Bitmap對象，然后將這個對象寫到字體的Charset中：
上面的攻擊代碼中，則將這個假的Bitmap對象的address0，也就是pBitsBuffer設置成了進行實際讀寫的bitmap的pBitsBuffer的地址。所以這個假的Bitmap對象就是我們上面提到的控制讀寫地址的Bitmap2。
最后下面就是完整的利用這個方式實現(xiàn)的任意內(nèi)核地址的讀(arbread)和寫(arbwrite)代碼:
3.修復內(nèi)核堆
由于漏洞是在上溢過程中進行的對前一個對象寫入，必然會對內(nèi)核堆造成破壞，所以必須要修復內(nèi)核堆的結構，這樣才能實現(xiàn)在進程退出，對象被釋放時不會造成系統(tǒng)藍屏崩潰，詳細的修復代碼可以參考源碼中觸發(fā)利用點之后的操作，篇幅關系就不在這里完全列出了。
4.實現(xiàn)權限提升
在實現(xiàn)了內(nèi)核任意地址寫入功能后，權限提升過程就比較簡單了，攻擊代碼通過遍歷內(nèi)核進程表找到explore.exe的進程token，直接將explore的token對象的地址寫入到當前進程的token中，并清除進程的Job對象，來實現(xiàn)最終完全繞過各類沙盒的保護功能。
由于權限提升過程中完全使用了DKOM的方式，沒有進行內(nèi)核代碼執(zhí)行，因此也繞過了Windows8以上系統(tǒng)中的SMEP內(nèi)核保護功能。
我們在分析這個漏洞的過程中，發(fā)現(xiàn)目前Hacking Team版本的漏洞利用代碼還是存在一些問題的，由于最終的提權代碼直接從Explore復制的token對象，會導致該token對象的引用計數(shù)出現(xiàn)問題，當系統(tǒng)關機、注銷，或者Explore.exe異常結束，最終導致Explore.exe進程退出時，可能會導致引用錯誤的token對象，引發(fā)系統(tǒng)藍屏崩潰，這是這個利用不夠優(yōu)美的地方。
當前文章：HackingTeam攻擊代碼分析Part3:字體0day漏洞
文章網(wǎng)址：http://m.5511xx.com/article/dpspdoi.html
