Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    April 2014
    S M T W T F S
    « Mar    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • About Us

    Several weeks ago, a new Adobe Acrobat/Reader zero-day vulnerability was found and soon exploited in the wild. What’s most interesting about this particular exploit is how it used return-oriented exploitation (ROP) techniques to bypass some of Windows’ security features such as Data Execution Prevention (DEP). In addition, it uses a two-staged shellcode to perform its routine. The first stage uses ROP techniques to load the second stage. The second stage is what actually executes the malicious behavior and is sprayed into memory by JavaScript within the .PDF file itself.

    Threats like these show how vulnerability threats, like malware, are evolving to become more sophisticated. Despite the best attempts of vendors such as Microsoft to incorporate new and emerging technology to make exploitation more difficult, those behind these threats are just as ready to grow and make life more difficult for users.

    Static Analysis

    Once we examined the .PDF file, we noticed a a suspicious FontDescriptor object in it. (A FontDescriptor object describes a font that has been used in the given .PDF file.)

    The font’s stream is encoded with FlateDecode. Once we decoded this and found the SING table, we immediately saw something suspicious. The uniqueName field here is supposed to be a 27-character string encoded with 7-bit ASCII encoding and null-terminated.

    However, the length of the data exceeds 28 bytes. This has all the hallmarks of a buffer overflow.

    Click for larger view

    Debugging

    Via static analysis, we now know which part of the .PDF file was used in the exploit. We can then use a debugger to verify this and see just how it was used. Once the malicious .PDF file was opened in Adobe Reader, a call to the strcat function was made. Let’s look at what was in the source buffer at the time.

    We have seen this “A8AAAAAA…” before. It was actually the content of the uniqueName field from earlier. The destination buffer is on the stack with a fixed size. Combined, this causes an overflow.

    After the overflow, a function pointer on the stack will be overwritten with the value 0x4a80cb38. This function pointer will be called later, effectively passing control of execution to the attacker.

    Return-Oriented Exploitation

    By itself, an overflow is not all that interesting nor unusual. However, this particular exploit used ROP to bypass one of Windows’ exploitation mitigation mechanisms, DEP. DEP tries to prevent attacks by disabling the execution of code that comes from nonexecutable pages in memory.

    ROP is designed to defeat DEP by using parts of already-loaded code that are marked executable to perform its routines. The logic in ROP is that for any sufficiently large code base, a working exploit can be formed by reusing existing code and forming a “chain.”

    The attacker chose the icucnv36.dll component of Reader to target. The said component does not support address space layout randomization (ASLR), which makes it more vulnerable to ROP attacks. The address mentioned earlier—0x4a80cb38—is the starting point in icucnv36.dll for this particular shellcode:

    4a80cb38 81c594070000 add ebp,794h
    4a80cb3e c9 leave
    4a80cb3f c3 ret

    These instructions serve as the start of the ROP chain by adjusting the stack pointer. Succeeding instructions point to the stack data used for the ROP chain. The stack data is sprayed into memory by JavaScript code within the malicious .PDF file. Here is a snippet of the code used:

    The highlighted part will be the double word in memory with the value 0x4a801064 after some replacement and unescape operations.

    The second stage shellcode, which actually performs the malicious routines, is also first sprayed into memory by JavaScript. After deobfuscation, this is what the code looks like:

    %u52e8%u0002%u5400%u7265%u696d%u616e%u6574%u7250
    %u636f%u7365%u0073%u6f4c%u6461%u694c%u7262%u7261
    %u4179%u5300%u7465%u6946

    This is native x86 code, which was used to carry out the actual malicious routines.

    Returning to the first-stage ROP code after adjusting the stack pointer, the code looks for portions of icucnv36.dll, calling several APIs:

    1. It calls CreateFileA to create a file named “iso88591” (the file name is not important).
    2. It calls CreateFileMappingA with flProtect=0×40 (allows the file to be executed).
    3. It calls MapViewOfFile to map the created file.
    4. It calls memcpy to copy the second-stage code to the buffer, which points to the beginning of the shared mapping file.
    5. It jumps to the beginning of the file-mapping buffer. Since the memory is executable, it bypasses DEP protection.




    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon






     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice