A few weeks ago, someone found a new zero-time-difference Adobe Acrobat/Reader vulnerability on the Internet and immediately began to exploit it. From a technical point of view, this attack is most striking because it uses the Return-Oriented Exploitation (ROP) vulnerability) tips to avoid Windows Data Execution Prevention (DEP) security mechanism. In addition, it uses two-stage attack program code (shellcode) to execute malware. The first stage uses the ROP technique to load the second stage of the program. The second stage is where malicious behaviors are actually executed, and JavaScript is used to load the program code in the. PDF file into the memory.
From these threats, we can see that malicious software that specifically attacks vulnerabilities is becoming increasingly sophisticated. Although Microsoft and other vendors have tried to add new technologies to prevent vulnerability attacks, it seems that hackers are not a fuel-saving lamp, and the user's days will not be too good.
Static Analysis
When analyzing the. PDF file, we found a suspicious FontDescriptor (font description) object internally. (The FontDescriptor object is used to describe the fonts used in the. PDF file .)
The font data is encoded using FlateDecode. When we deploy it, we can see a SING table and immediately discover suspicious content. Its uniqueName (unique name) field should be a 27-character string that adopts 7-bit ASCII encoding and ends with NULL.
However, the data here exceeds 28 characters. This is a typical Buffer Overflow.
Debugging
We learned from the static analysis what part of the. PDF file is used by this vulnerability. Next, we will use the debugger to verify our opinion and see how it actually works. When this malicious. PDF file is opened in Adobe Reader, strcat is called. Let's take a look at the source buffer content of this function call.
We have read "A8AAAAAA ...」 This section. This is the actual content of the previous uniqueName field. The destination buffer is a fixed-size stack. Therefore, the buffer overflow occurs.
After the buffer overflow, a function indicator on the stack is overwritten as 0x4a80cb38. Next, the attacker will call this function indicator to gain control over program execution.
Response indicator vulnerability attack
In fact, buffer overflow is not too serious or unusual. However, this attack uses the ROP technique to bypass the DEP mechanism used by Windows to prevent vulnerability attacks. The DEP mechanism prevents the system from executing non-executable memory pages.
However, the drop-down technique overwrites the loaded executable code to execute the program, cleverly avoiding the DEP mechanism. The logic behind ROP is that, as long as the program is large enough, attackers can use the existing program code to form a program code "serial ".
The attacker chose Adobe Reader's icucnv36.dll component as the target. This component is not configured to use the Address Space Layout Randomization (ASLR) function, so it is easy to become the target of the ROP attack. The above address (0x4a80cb38) is the starting point of the following attack program code in icucnv36.dll.
4a80cb38 81c594070000 add ebp,794h4a80cb3e c9 leave4a80cb3f c3 ret
|
You just need to modify the stack pointer, and this program code will become the starting point of the ROP serial. The subsequent program code points to the stack data used as the ROP serial. The stack data content uses JavaScript in the malicious. PDF file to load the memory. The following is a piece of program code used for this attack:
After some replacement and anti-Skip operations, the part shown in the box is a value of the double word size in the memory: 0x4a801064.
The second-stage attack program code that truly has malicious behaviors is first loaded into the memory by JavaScript. After decoding, the real program code should be as follows:
%u52e8%u0002%u5400%u7265%u696d%u616e%u6574%u7250%u636f%u7365%u0073%u6f4c%u6461%u694c%u7262%u7261%u4179%u5300%u7465%u6946
|
This is a native x86 machine code used to execute real malicious attacks.
Return to the first stage of the ROP program after the stack pointer is adjusted. The program code searches for some parts of icucnv36.dll and calls several APIs:
Call CreateFileA to create a file named "iso88591" (the nickname is not important ).
Call CreateFileMappingA and specify flProtect = 0 × 40 (to make the file executable ).
Call MapViewOfFile to map the created file.
Call memcpy to copy the second-stage program code to the buffer, that is, the beginning of the ing shared file.
Next, the program jumps to the beginning of the buffer where the image file is located for execution. This zone is executable memory, so we can avoid the DEP protection mechanism.
Note: Yuki Chen is now a threat solution engineer at Trend Micro.