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:

Security News

The SonicWall Capture Labs Threat Research Team gathers, analyzes and vets cross-vector threat information from the SonicWall Capture Threat network, consisting of global devices and resources, including more than 1 million security sensors in nearly 200 countries and territories. The research team identifies, analyzes, and mitigates critical vulnerabilities and malware daily through in-depth research, which drives protection for all SonicWall customers. In addition to safeguarding networks globally, the research team supports the larger threat intelligence community by releasing weekly deep technical analyses of the most critical threats to small businesses, providing critical knowledge that defenders need to protect their networks.