這筆字型數(shù)據(jù)采用FlateDecode方式編碼。當我們將它解?之后，我們看到一個SING表，并且立刻發(fā)現(xiàn)了可疑的內(nèi)容。其uniqueName（獨特名稱）字段應該是一個采用7位ASCII編碼且用NULL字符結尾的27字符字符串。

但是，此處的數(shù)據(jù)卻超過28個字符。這就是典型的緩沖區(qū)溢出。

除錯

我們從靜態(tài)分析得知此漏洞攻擊使用了.PDF檔案中的哪一部分數(shù)據(jù)。接下來，我們要運用程序除錯器（debugger）來驗證我們的看法，并且看看它實際上如何運作。當這個惡意.PDF檔案在Adobe Reader中開啟時，會呼叫strcat函式。讓我們來看看此函數(shù)調(diào)用的來源緩沖區(qū)內(nèi)容。

我們已看過「A8AAAAAA…」這段內(nèi)容。這就是先前uniqueName字段的實際內(nèi)容。而目的地緩沖區(qū)則是一個固定大小的堆棧。正是因此才會造成緩沖區(qū)溢出。

在緩沖區(qū)溢出之后，堆棧上的一個函式指標就會被覆寫成0x4a80cb38。接著后面會呼叫這個函式指標，攻擊者就因此獲得程序執(zhí)行控制權。

返回指標漏洞攻擊

其實緩沖區(qū)溢出本身并不是太嚴重或太不尋常的問題。但是，這項攻擊利用了ROP技巧來避開Windows用來防止漏洞攻擊的DEP機制。DEP機制可以防止系統(tǒng)執(zhí)行非可執(zhí)行內(nèi)存分頁中的內(nèi)容。

但ROP技巧會覆蓋已加載的可執(zhí)行碼來讓自己的程序執(zhí)行，巧妙地避開了DEP機制。ROP背后的邏輯是，只要程序夠大，就能讓攻擊程序運用現(xiàn)有的程序代碼來組成一個程序代碼“串行”。

此攻擊的作者選擇了Adobe Reader的icucnv36.dll組件為目標。此組件并未設定使用地址空間配置隨機化（Address Space Layout Randomization，簡稱ASLR）功能，因此才會輕易成為 ROP 攻擊的目標。前述的地址（0x4a80cb38）就是icucnv36.dll內(nèi)以下這段攻擊程序代碼的起點。

只要修改一下堆棧指針，這段程序代碼就會變成 ROP 串行的起點。后面接著的程序代碼則指向用來做為ROP串行的堆棧數(shù)據(jù)。堆棧數(shù)據(jù)內(nèi)容則是使用惡意.PDF檔案內(nèi)的JavaScript來加載內(nèi)存內(nèi)。以下是一段這項攻擊所用到的程序代碼：

框出來的部分經(jīng)過一些置換和反跳位運算之后，最后在內(nèi)存內(nèi)是一個雙字組（double word）大小的數(shù)值：0x4a801064。

真正具備惡意行為的第二階段攻擊程序代碼一開始也是先由JavaScript加載內(nèi)存內(nèi)。在經(jīng)過解?之后，真正的程序代碼應該像下面這樣：

這是原生 x86 機器碼，用來執(zhí)行真正的惡意攻擊。

回到堆棧指針調(diào)整好后的第一階段ROP程序，其程序代碼會搜尋icucnv36.dll的某些部分，并且呼叫幾個API函式：

呼叫CreateFileA來建立一個名為“iso88591”的檔案（?名不重要）。

呼叫CreateFileMappingA，指定flProtect=0×40（讓檔案可執(zhí)行）。

呼叫MapViewOfFile來映像剛才建立的檔案。

呼叫memcpy來將第二階段的程序代碼復制到緩沖區(qū)，也就是此映射共享檔案的開頭。

接著，程序跳到映像檔案所在的緩沖區(qū)開頭來執(zhí)行。由于此區(qū)為可執(zhí)行的內(nèi)存，因此就能避開DEP保護機制。

分享到

liukai

相關推薦