這筆字型數(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

相關推薦