New PDF Exploit uses 2 new vuln's + JJencode ~ Anti-Malware Laboratory

Last week, a new zero-day exploit has been found in the wild. The exploit is a vulnerability that allows attackers to escalate privilege and execute code in kernel or ring0 mode. More details of the CVE-2013-5065 vulnerability can be found in this Microsoft website. After we got a sample of the supposed PDF that was used in the targeted attack,we immediately went to work and here's what we found.

Close inspection of the raw file reveals that it contains a strange looking script at the end of its body. No clue can be obtained as to what this script is doing at initial glance. However, one of our colleague indicated that this obfuscation technique is already widely used by malicious scripts and has been out for some time now. The obfuscation itself is not malicious but since it provides the stealth and complexity that most malicious scripts require, it is favored by more malware authors. This obfuscation is called jjencode. More details about this technique can be found on this blog. De-obfuscating it was a trivial matter, and it can be easily seen that the script contains shellcode that is intended to be executed using an exploit technique ROP (return objected programming).

De-obfuscated script

The thing is, the supposed exploit code that escalates privileges using DeviceIoControl cannot be read on the said script, which probably is contained in the shellcode. And in order to make the shellcode work, it would require another exploit in the PDF. So in theory, this PDF malware needs two exploits in order for it to successfully attack the system. Knowing this, we went ahead and analyzed the PDF, made breakpoints on strategic places to catch its shellcode in action.

ROP in action

The picture above shows the script was able to put its shellcode in memory. It shows that the script has already gained control of the call stack. It will use a technique called ROP (return oriented programming), since normal buffer overflows would not work in this part of memory where security protections are implemented.

Allocates memory using CreateFileMapping with FFFFFFFF handle

Copies 0x400 bytes of shellcode in newly allocated memory

It uses a specific DLL where it would implement its API calls, allocates a separate memory region where it would resume the bulk of its shellcode action using CreateFileMapping. Once it successfully copies its shellcode in the new memory, it gets the APIs that it needs using hashes.

Comparison of hashes for needed API

ExitProcess
VirtualAlloc
DeviceIoControl
CreateFileA
GetCurrentProcessId
LoadLibraryA
WinExec
WriteFile
CloseHandle
GetTempPathA
GetTempFileNameA
GetFileSize
ReadFile
SetFilePointer

The picture below shows the shellcode attempts to invoke CreateFile with the given argument. This buffer should point to a string "\\\\.\\NDProxy", where it should give a handle and calling DeviceIoControl should perform the exploit EoP (Escalation of Privilege). In turn, this would allow the code to execute a dropped executable with a TMP extension in the %TEMP% folder. However, as you may have noticed, the initial code only copied 0x400 bytes of its code in the new memory. And the pointer to the buffer in CreateFileA indicates the string is located at offset 0x40e...