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
