测试版本:AcroRdrDC1700920044_en_US

漏洞模块: 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的入口函数。

完事收工。