2. • What is CVE-2014-4113 Zero-day flaw fixed in the October Patch update is CVE-2014-4113, which is privilege escalation vulnerability. This flaw too has been actively exploiting users. Security firm Crowd strike is attributing attacks leveraging CVE-2014-4113 to a Chinese malware group that it refers to as Hurricane Panda.
3. Crowdstrike isn't the only security vendor that detected CVE-2014-4113, as Fire Eye also reported the issue to Microsoft.
win32k.sys in the kernel-mode drivers in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows local users to gain privileges via a crafted application, as exploited in the wild in October 2014, aka "Win32k.sys Elevation of Privilege Vulnerability."
4. • Vulnerable products
Microsoft Windows Vista Service Pack 2 0
Microsoft Windows Server 2008 R2 for x64-based Systems SP1
Microsoft Windows Server 2008 for x64-based Systems SP2
Microsoft Windows Server 2008 for Itanium-based Systems SP2
Microsoft Windows Server 2008 for 32-bit Systems SP2
Microsoft Windows Server 2003 Itanium SP2
Microsoft Windows 7 for x64-based Systems SP1
Microsoft Windows 7 for 32-bit Systems SP1
Microsoft Exchange Server 2003 SP2
5. • Vulnerability & Exploit Details
The 32-bit exploit triggers an out-of-bounds memory access that dereferences offsets from a high memory address, and inadvertently wraps into the null page. In user-mode, memory dereferences within the null page are generally assumed to be non-exploitable. Since the null page is usually not mapped – the exception being 16-bit legacy applications emulated by ntvdm.exe–null pointer dereferences will simply crash the running process.
6. In contrast, memory dereferences within the null page in the kernel are commonly exploited because the attacker can first map the null page from user-mode, as is the case with this exploits. The steps taken for successful 32-bit exploitation are:
1) Map the null page: ntdll!ZwAllocateVirtualMemory(…,BaseAddress=0×1, …)
2) Build a malformed win32k!tagWND structure at the null page such that it is properly validated in the kernel
3) Trigger vulnerability
4) Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode Callback overwrites EPROCESS.Token to elevate privileges
5) Spawns a child process that inherits the elevated access token
7. 32-bit Windows 8 and later users are not affected by this exploit. The Windows 8 Null Page protection prohibits user-mode processes from mapping the null page and causes the exploits to fail.In the 64-bit version of the exploit, dereferencing offsets from a high 32-bit memory address do not wrap, as it is well within the addressable memory range for a 64-bit user-mode process. As such, the Null Page protection implemented in Windows versions 7 (after MS13-031) and later does not apply. The steps taken by the 64-bit exploit variants are:
8. 1) Map the null page: ntdll!ZwAllocateVirtualMemory(…,BaseAddress=0×1, …)
2) Build a malformed win32k!tagWND structure at the null page such that it is properly validated in the kernel
3) Trigger vulnerability
4) Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode Callback overwrites EPROCESS.Token to elevate privileges
5) Spawns a child process that inherits the elevated access token
9. 64-bit Windows 8 and later users are not affected by this exploit. Supervisor Mode Execution Prevention (SMEP) blocks the attacker’s user-mode callback from executing within kernel-mode and causes the exploits to fail.
10. • Vulnerability and Patch Analysis
Microsoft recently patched some vulnerability; vulnerabilities, Let’s Go through the Vulnerability CVE-2014-4113.which are local kernel vulnerability that successful exploitation would give you SYSTEM access.
Let’s Go
I Got Vulnerable and patched (KB3000061) win32k.sys and Put them in two separate folders and Placed each them versions of win32k.sys inside them
11. Using IDA I have loaded them and saved. Then I had to find out what is Change In Patched version, TurboDiff I used, simply gives plain-text table Of changed functions. For this patch I got 25 changed functions, Started checking each changed functions. In Internal function of xxxHandleMenuMessages Found patched versions have additional check for returned value from xxxMNFindWindowFromPoint (internal function).
12. That check was a call to IsMFMWFPWindow function and parameter to IsMFMWFPWindow was exactly return value of xxxMNFindWindowFromPoint. So I figured out that here something was wrong and Microsoft added a code to check return value of xxxMNFindWindowFromPoint.
17. Then started to think about exploitation method for this vulnerability, how to trigger this vulnerability and make xxxHandleMenuMessages API to call xxxSendMessage with an invalid HANDLE. Found that the vulnerability is related to window system and possible NULL value during xxxHandleMenuMessage process, I just remembered this. For exploiting that, you had to map zero/null page, create a fake object at zero page and trigger the vulnerability. So this was the general idea, now had to find a way to trigger this vulnerability by causing xxxHandleMenuMessage call xxxSendMessage with a NULL handle.
18. Fortunately found PoC published online for this vulnerability, instead of trying to solve it on my own as a practice/challenge, just downloaded the sample and started to analyze it. Lots of things was as I thought, the only missing part in chain of exploitation was how to make that NULL in xxxHandleMenuMessage. It was done by hooking and altering parameters in user mode. So basically the PoC deletes the menu and returns -5,so xxxSendMessage will use a tagWND object starting from -5 (0xFFFFFFFB) to positive values which is in user-mode.
19. The PoC allocated zero-page using ZwAllocateVirtualMemory with 0x01 as base address and writes a fake tagWND object here. Windows allows zero page allocation for 16-bit application compatibility/support. So the tagWND object have two important parts, one is WS_EXECUTE_IN_KERNEL flag which is at offset ((BYTE*)&pWnd->state)+0x02 and the other one is callback function which is at offset 0x60. So by setting 0x16 to 0x04, you are telling kernel that the callback functions at 0x60 needs to be executed in kernel. So the PoC modifies return value (returns -5) by hooking, but before that, it writes 0x04 to 0x16 - 0x05 (0x11) offset (WS_EXECUTE_IN_KERNEL flag) and address of shell code at 0x60 - 0x05 (0x5B).
20. The shell code does nothing other than replacing current process token with SYSTEM process (pid = 4) token. Therefore, any process created by current process will have SYSTEM token too.
21. Cyan color holds address of shell code and yellow background holds WS_EXECUTE_IN_KERNEL flag. For triggering the vulnerability, simply it creates two layer popup menu (one main popup menu and one sub menu inside it), then it calls TrackPopupMenu to trigger the hook. In hook function, it replaces window handler using SetWindowLongA API.
23. That was it. Using this simple hooking and altering popup menu, kernel will call and execute callback function at null page, in kernel space. I think I've said enough about this bug. So please update your OS, specially servers, as soon as possible, because lowest access (for example ASP.NET shell with ASP.NET user account) can get SYSTEM access using this vulnerability.
25. It should come as no surprise that it is possible to exploit a kernel vulnerability where we are able to fully control the content of a moderately large kernel structure such as win32k!tagWND. The described exploit was specifically developed on Windows 8.1, but it turned out that the same technique worked on Windows 8 as well. Compared to the public exploit where the function returning the bad win32k!tagWND reference and the call to the overwritten function pointer is pretty close to each other, this is different for the described technique on Windows 8 and Windows 8.1.
26. A lot of code is executed until the code is reached which finally triggers the memory corruption. Since we didn’t fully reverse engineer all the code in between, there could be certain unexpected code paths which could make the described exploit fail. Although the exploit worked quite reliably in our tests, we don’t make any claims for a hundred percent reliable exploit.
27. So consider it proof of concept In summary, even with the presence of protection mechanisms like SMEP, with full control over a moderately large kernel structure there are enough possibilities to trigger a simple memory .corruption in order to achieve the desired goal and be able to escalate privileges without overwriting any function pointers or executing any shell code at all.
