Adobe Reader, CVE-2013-3346 and Windows, CVE-2013-5065 Exploit Analysis (January 10, 2014)
In December, we reported an attack that leverages a combination of Adobe Reader Vulnerability(CVE-2013-3346) and a Windows Local Privilege Escalation Vulnerability(CVE-2013-5065). These vulnerabilities are already patched by their respective vendors.
The following write up explains in detail how these vulnerabilities are exploited.
Attack Flow
Analysis of CVE-2013-3346
This is a use-after-free vulnerability in Adobe Reader which can be exploited using specially crafted PDF file.
The Exploit PDF has an obfuscated JavaScript Stream.
After De-obfuscation, we can see code-piece that has shellcode, heapspray, payload, ROP
Here, the exploit is fine tuned for Adobe Reader 10 and 11.
The following is the minimum crash code.
Here are some debugging images.
The following shows crash, normal execution and call in the corrupted structure.
This is how the corrupted structure looks like. We can see how the call pivots into the ROP Chain.
This is a subset of ROP Chain
Now a sequence of functions is called which ultimately drop and execute malicious binary.
Analysis of CVE-2013-5065
This is a local privilege escalation vulnerability that could lead to code execution in ring0 context. The vulnerability exists in Microsoft’s NDProxy driver. The vulnerability is triggered due to out of bound condition in the ioctl handler.
The proof of concept code is as follows:
The ‘CreateFile’ function opens NDProxy through I/O. As quoted in MSDN – “NDPROXY is a system-provided driver that interfaces NDISWAN and CoNDIS WAN drivers (WAN miniport drivers, call managers, and miniport call managers) to the TAPI services.” DeviceIOControl is then used to send the control code directly to NDProxy driver. The code here is 0x8fff23cc.
There’s no detailed documentation on this code – so let’s look at NDProxy.sys (v5.1.2600.5512)
There’s PxIoDispatch(…) function that handles the codes
As you can see, the code 0x8fff23cc corresponds to the execution of the code in the box. Also note in the highlighted red box, ‘eax’ equals to 0x7030125 which is the value that was passed to DeviceIoControl function above as a part of the ‘InBuff’ [*(InBuf+5)]. Subtracting 7030101h from this gives 0x24. Let’s try to figure that out by debugging the sample. Executing the sample produces a crash :-
Let’s look at the crash using Windbgs “analyze !v”
And the state of the registers:
As seen, the EIP points to 0x38 (crash).
Let’s look at NDProxy!PxIODispatch+0x2b3 :
The call invokes in to an array with starting offset at off_18008. The index for the highlighted call is ‘eax’ which is 0x1b0 as you can in the state of the registers above. So, 0x18008 + 0x1b0 = 0x181B8. Looking at this address:
And it points to 0x38 – exactly the place where EIP was during the crash. Thus, the value 0x7030125 is chosen carefully to lead to this crash.
Following is the Flow :
Dell SonicWALL protects against this threat with the following signatures:
- GAV: Inject.DKI (Trojan)
- GAV: Pidief.SKD (Exploit)
