漏洞模塊: Escript.api

漏洞函數

修復函數

問題分析

拷貝對象的時候把DWORD類型的對象地址作為BYTE類型進行了拷貝，堆對象拷貝溢出漏洞。對象偏移在0x50的地方，也就是錯誤的位置。

Javascript裏面噴射的對象代碼。

修復方案

定位到問題很好修復。

ROP技術

使用EScript.api模塊作為ROP執行地址，基址為69260000，ROP表如下.

• 0D130064 692E2803 EScript.692E2803
• 0D130068 692E2803 EScript.692E2803
• 0D13006C 692E2802 EScript.692E2802
• 0D130070 693F7084 <&KERNEL32.VirtualAlloc>
• 0D130074 69271784 EScript.69271784
• 0D130078 693EAF26 EScript.693EAF26
• 0D13007C 69278000 EScript.69278000
• 0D130080 69283AAA EScript.69283AAA
• 0D130084 6936F282 EScript.6936F282
• 0D130088 00010201
• 0D13008C 692E2802 EScript.692E2802
• 0D130090 692695C4 EScript.692695C4
• 0D130094 77842FB6 kernel32.VirtualAlloc
• 0D130098 69283AAA EScript.69283AAA

第一條ROP指令RETN在692E2803，為一條RETN指令。因為有ASLR保護，所以地址看起來不一樣。

ROP指令不進行一一講解，接下來通過ROP技術構造了一個函數VirtualAlloc分配一段內存。註意看下EAX寄存器的值。

EAX是0x90909090，adobe的javascript的堆噴射器裏面也有0x90909090。

使用VirtualAlloc函數申請了一段可讀可寫可執行的內存，大小為66049字節。為什麽呢?因為惡意pdf裏面還有個pe文件，shellcode應該帶有一個pe加載器，直接在本進程在內存執行pe文件。

接下來返回到了惡意內存中的shellcode繼續執行。註意一下，前面4字節是0x90。說明那個是填充的NOP指令。

Shellcode

第一個功能就是在shellcode長度(0x2710字節長度)後面搜索一個4字節的標記0xBFAFBFAF。搜索標記的作用是定位PE頭。

接下來用經典的fs:[0x30]技術定位kernel32的基址。

接下來通過解析PE文件搜索GetProcAddress函數的地址，這也是windows經典的shellcode技術。

使用GetProcAddress函數得到LoadLibraryA、VirtualAlloc、VirtualFree、VirtualProtect、GetModuleHandleA的地址

接著是PE加載器的經典功能，拷貝PE頭、修復區段、重定位、填充輸入表等等。

接著使用VirtualProtect函數改寫PE為可讀可執行可寫。

最後調用PE文件的入口函數，因為PE是dll所以入口是DllMain。

這個dll只有一個功能，使用MessageBoxA彈一個對話框。

Dll的入口函數。

完事收工。

原文地址：https://mozhe.cn/news/detail/294

CVE-2018-4990 漏洞詳情分析