Wednesday, December 16, 2009

New Zero day Adobe Acrobat Reader vulnerability analysis – Part 2

Earlier, in the first blog of this series we talked about a malicious PDF file and extracted the malicious script. Now, we have a malicious script in readable format and want to know if this successfully runs or not. I am not going to run the original malicious file for now. I will replace the original shellcode with a simple one which will open a “calc.exe” after successful exploitation. The problem is the original malicious PDF file is in encoded format so we can’t edit the malicious script inside the file. For that I will create a new test PDF file using “make-pdf-javascript.py” tool from PDF Tools. This tool will create a simple PDF file containing JavaScript which will display a message box once opened. I am going to add malicious JavaScript code inside this file using command,

D:\make-pdf-javascript.py --javascriptfile=Malicious_Script.js test.pdf

I am going to use another shellcode which will open “calc.exe”. Here is the newly created PDF file:

Let’s open it and see if this exploit works. This time it only crashed and did not opened a “calc.exe”. But I got a chance to look into the debugger. Here is the state of the ollydbg debugger,

The EDX currently points to zero and it is trying to CALL DWORD from [EDX +4]. Since it is zero, it has an access violation exception. Further we found that the module is “C:\Program Files\Adobe\Reader 9.0\Reader\plug_ins\Multimedia.api”. Let’s change some EDX values manually in the debugger to see if this is going to work or not? Since we have already filled a heap we need to change values accordingly. I found our NOP sled and shellcode gets loaded at “0A0A0A0A” address, so this is the value we are going to use. Here is the state of ollydbg once I modify the values,

Now, EDX points to “0x0A0A0A0A” address and [EDX + 4] contains address “0x0A0A0A20” which is our NOP sled. So once I press “F9” (run) button in Ollydbg, it will jump to “0A0A0A20” address and will execute everything from there on. You can see this step by step during debugging. Yes, it has executed the NOP sled and our shellcode and “calc.exe” opened on the machine. But this was done by changing the values manually. It looks like there is problem with memory corruption. I played a little bit with the code and found that we have to add one more line of the vulnerable function before try{} block. Here is how new modified code will look,

Once I run this file again, the shellcode executed successfully and it showed a classic POP up box with error message and opened “calc.exe”,

From above, it is clear that there is memory free issue with the vulnerable method “util.printd()”. It required calling this method twice with the try {} block. The code gets executed successfully and opened a calculator. This means if we now remove the “calc.exe” shellcode and use the original shellcode, then it is going to execute in the background without any notice. I am not going into more details of the original shellcode this time due to length of the blog post.

That is it for this series.

Umesh

6 comments:

Anonymous said...

Hi Umesh,

Could you send me the calculator .PDF demo, so as to test it?

Regards
Javier
javier_falbo@hotmail.com

Anonymous said...

Not entirely clear why you need to enter the "util.printd" function twice. Why is this the case? The original PDF simply crashes for me. Surely it will not work in the wild if this happens?

Anonymous said...

Hey, I am trying to follow this guide and step through the exploit in the debugger. It is not working correctly. How did you get it to break on the memory access violation at ecx+4?

Umesh Wanve said...

Did you created new PDF file for testing? Check out the version of OS and Adobe while testing also try to change to shellcode or remove it and then open it and attach the debugger. You should get a crash

Anonymous said...

I used a malicious PDF with the exploit and it crashes. I just cannot hit the piece of code that you have identified at 2D842F8B. Which is CALL DWORD PTR DS:[EDX+4]

Anonymous said...

hi umesh,

can you send me the javascript file, from you are calling CALC.EXE

please send me on ankitnirmal@yahoo.com