Tuesday, December 29, 2009

Adobe CVE-2009-4324 in the wild - (0day) - part 0.6 – from Taiwan govs with low detection


Through the  contagiodump.blogspot.com report, in this post will be analyzed a PDF with characteristics different from those in previous posts.  The document it’s collected through a mail attachment as well shown in the contagiodump blog:

s004

(http://contagiodump.blogspot.com/2009/12/dec-29-cve-2009-4324-adobe-0-day.html)

In particular, as the first step, the file it’s been opened with an editor (Notepad++).  As always there are some tags that require decoding Inflate to get the code in the clear. But a note of interest it’s been discovered: (since I’m not a PDF specs guru) in  the following statement

s001

In the screen shot above there is a red note that it’s easily confirmed following this Google query:

s002

The /DL token it’s explained in the PDF Specs at following link: http://www.adobe.com/devnet/pdf/pdf_reference.html
In addition the red note  is confirmed by analyzing the Metasploit module for generating exploitable PDF files as shown in the following screen shot:

s003

(From http://www.packetstormsecurity.org/0911-exploits/adobe_pdf_embedded_exe.rb.txt)

In conclusion the PDF stub it maybe generated with Metasploit module. Returning to the analysis using pdf_inflater the only Javascript clear code file obtained is the following:

s005

IMHO this code contains a “not so bad” methods for a good low detection technique.

The shellcode (variable name “sc”) it’s obtained, function urpl at line 1, replacing the “Z” char with “u” obtaining the following UCS2 stream:

s006

Using Malzilla it’s been obtained the following hex stream ready to been posted at http://sandsprite.com/shellcode_2_exe.php

d9c8d97424f4bae7dbd3bc29c95fb19f31571483082731446
c375250e7d8d3bc0f93d1bce752964818ae27d4d41159e70f
3bd2bce752965018ae27d4a8d814030f0bd2bce752965418a
e27d442ccd3c00f1bd2bce752965818ae27d44a40ae630f6b
d2bce752965c18ae27d44bd309ca0f7bd2bce752966018ae2
7d4f1be29ac0f4bd2bce752966418ae27d4f8a2d9540f5bd2
bce752966818ae27d41c4c2eb30fabd2bce752967018ae27d
40b4cd0b00fbbd2bce752960418ae27d411f96ac00f8bd2bc
e752960818ae27d4646266c40f9bd2bce752961018ae27d40
1cc5cc70febd2bce752967818ae27d47f2559b20ffbd2bce7
52967cd42d507ae356961cb78d2ce907e6234ee6dba6526ea
e7335a2274a37aa2782ee188e6b35a2734aeeb5892cc94724
86606a864325b5882cc91b24a61418ae7343b20358f94f9b5
284a1f589d4922c52c4e3f8d53dfeae3d3197d758fcef5296
446eae773162db2d43188bbb2ce6dbd343b2375e39e7252c4
3b7248654205ed342182492df95891439e3252c4383e8e192
205edb42182496e4a2dbb9bc8dd9b9b88ddbb9bf8fdbd3bca
75656bc19242cec188e3735a24758c943502d37aa23b31164
23d3c8e2ee0f663b0178f5ae923153864281ef18ae2bea18
e4f43b20f8543b26f2cc97b248670205ed342182492df9589
1439e3252c4383e8e192205edb42182496e4a2dbb9bc6a5ed
3421824832c7724867c188e17d6e78b2ce94b8886eab050bf
98ff5096806c8fd6c4e40e58f6ff50899ce406308eae50e73
7e42ee0431be81310dd1fa7bb2614debf1f3021879bffc7c9
06508998e406b537eb9058e6fbd80e37e350d0790cd9e07c6
c0e8ce2ba8011b4e78db71dd7dbd3bc621babb06c9bdf3797
c77e37a7d338b56c9be7376763d3bce785102c

Trying to analyze the shellcode  the first step it’s bypass an anti debugging technique. For this goal it’s been pressed the “F7” step by step debugging mode option of IDA Pro. Don’t use “F8”. (many thanks to http://whsbehind.blogspot.com/ for the hints). In this mode it’s possible decrypt (XOR with 0xBCD3DBE7 in EDX) the first piece of runtime code and following in the subsequent steps:

s007

And the following screen shot it’s a step before the setting and jump to the new value of EIP:

s008

The assembly code now it seem interpretable by IDA:

s009

For the shell code, it’s possible analyze the runtime code until a certain point. After it must continue with the static analysis of code and in some cases this approach may be not a good approach. The best approach is run Adobe Reader under debugger, open the malicious PDF file, and identify pieces of code involved in the exploiting and execution of shell code. By way of example on the next screen it’s shown a file size checking conducted by the standalone shell code. In the following picture the shell code it’s executed out from Adobe Reader context, or if you prefer in “standalone mode”. In this condition  there aren’t open PDF file handles. Then ,as in this case, running standalone shell code leads to a condition of infinite loop. So, in conclusion, it’s necessary loading the malicious PDF in the an Adobe Reader context and tracking the behavior with an application debugger.

s010

The 127728 bytes is the size of the PDF file:

image

Trying to analyse the shell code under the Adobe Reader context its been detected the following code from which start to a better analysis:

s011

It’s shown the Multimedia.API plugin code zone where it’s handled the method that trigger the issue. The screen shot above potentially contains info that may be used as starting point for writing  “third part” patch.

For other behaviors like network traffic, dropped file, and system activities please check http://contagiodump.blogspot.com/2009/12/dec-29-cve-2009-4324-adobe-0-day.html.

8 comments:

  1. Very comprehensive analysis. Thanks for sharing

    Keep it up!

    ~x9090
    http://x9090.blogspot.com

    ReplyDelete
  2. When trying to look at this exploit in a debugger I cannot get the debugger to break on that code within Multimedia API plugin. Can you advise on how you reached it?

    ReplyDelete
  3. Mark try to add, as additional file, the multimedia.api (it's a dll).

    ReplyDelete
  4. Not quite sure what you mean by adding the DLL. How? Will adobe not call it? The exploit causes a crash, but it is after the memory access violation and I have to trace back to reach the offending EDX+4.

    I second x9090's statement, a lot of great analysis here. Keep it up

    ReplyDelete
  5. Try to add the multimedia.api with IDA (menu file and so on). Or if you prefer save before an idb file from adobe reader main exe file, open it with IDA, launch adobe reader, and attach to runtime process. The screenshot it's based on Adobe Reader 9.2 so try to check which version you have it. And obviously try to check that the pdf it contain an exploit for Multimedia method.

    ReplyDelete
  6. Very helpful analysis. Just have a question:

    I ran SpiderMonkey js against the encoded shellcode and it returned "d9 d9 24 ba ...".

    Looks like half of the hex stream has been truncated in comparison to yours. Can you please shed some lights on this?

    ReplyDelete
  7. for the shellcode analysis check out sclog from the idefense malcode analyst pack. It works with the byte buffers created by shellcode_2_exe. it can make dump of decoded bytes and does api log of its actions. pretty handy

    ReplyDelete