An Analysis of A Windows Kernel-Mode Vulnerability (CVE-2014-4113)

Three zero-day vulnerabilities - CVE-2014-4114, CVE-2014-4148, and CVE-2014-4113 - were reported last week and patched by Microsoft in their October 2014 Patch Tuesday. CVE-2014-4114, also known as the Sandworm vulnerability, can enable attackers to easily craft malware payloads when exploited.

This particular vulnerability has been linked to targeted attacks against European sectors and industries. In addition, our researchers found that Sandworm was also being used to target hit SCADA systems.

The latter two vulnerabilities (CVE-2014-4148, CVE-2014-4113) leveraged vulnerabilities in the Windows kernel (Win32k.sys), affecting most Windows versions. In 2013, only one Windows kernel zero-day, was made public; this particular vulnerability only affected some versions of Windows XP and Windows 2003. These new zero-days could be a sign that attackers are possibly shifting their focus back to kernel vulnerabilities.

CVE-2014-4113 allows for the elevation of privileges when exploited successfully. Microsoft addressed this inMS14-058. The vulnerability affects both desktop and server versions from Windows XP and Server 2003 up to Windows 8.1 and Server 2012 R2. However, the currently available exploit code does not affect Windows 8 and later versions.

With a parameter in the command line, the exploit code can create new processes with System privileges of an assigned program. EoP exploits are also believed to be used in targeted attacks, since the exploitable application does not have the privileges needed by attackers. This was seen in Stuxnet which employed CVE-2010-2743 (also in Win32k.sys) to EoP after using other exploit to infect system.

The analysis of this vulnerability and its exploit will be based on samples with the following MD5 hashes:

• 70857e02d60c66e27a173f8f292774f1
• f9f01ce747679b82723b989d01c4d927

We detect these as TROJ_APOLMY.A and TROJ64_APOLMY.A, with the latter being the version found on 64-bit systems.

Everything you need to know about the Win32k.sys vulnerability

Win32k.sys is responsible for window management, and any GUI process/thread that will use it. Its related user-mode modules are user32.dll and GDI32.dll. Due to the complex interaction with user-mode applications, there are many problems in Win32k.sys.

Let’s take a closer look on the vulnerability being exploited. The essential problem is the function return value is not validated correctly. Programmers tend to overlook this, but doing otherwise is a serious security risk.

In Win32k.sys, there is a function called xxxMNFindWindowFromPoint(), which returns the address ofwin32k!tagWND structure or error code -1, -5. Another function xxxHandleMenuMessages() will call it and use its return value as parameter of xxxSendMessage(). Below is the pseudo code:

xxxHandleMenuMessages()

{

tagWnd* pWnd = xxxMNFindWindowFromPoint(…);
…   //without checking if the return value is a valid address
xxxSendMessage(pwnd,…);

}

Obviously, if the error code -1 or -5 is used in xxxSendMessage() as an address, it will result in an error, such as a blue screen. In user-mode code, this is currently not exploitable. We will  see how the sample exploits this vulnerability in kernel-mode in the next section.

Below are the key steps or description on how the exploit occurs:

• Map a prepared memory section to NULL page, which includes a fake win32k!tagWND structure and a pointer to shell code for EoP in that structure.
• Trigger the bug and make the return value (pWnd) of xxxMNFindWindowFromPoint() to be -5 (0xfffffffb). Because all to-be-checked fields in the fake structure are accessible and in proper values,xxxSendMessage() will treat -5 as a valid address. It will then call a function pointer in the structure, which is the pointer to the shell code.
• Replace the token in EPROCESS to elevate to SYSTEM privileges in shell code.
• Create a child process with SYSTEM privileges of the assigned program

The sample uses SetWindowsHookEx() to control xxxMNFindWindowFromPoint() to return -5:

1. Create a window and 2-level popup menu.
2.  Hook that window’s wndproc call.
3. Track popup menu on the window and enter hook callback.
4. In the hook callback, it changes wndproc of the menu to another callback.
5.  In menu’s callback, it will destroy the menu and return -5 (PUSH 0xfffffffb; POP EAX)
6. Lead to xxxMNFindWindowFromPoint() on the destroyed menu return -5

Furthermore, the shell code of the sample is simple and direct, as can be seen from the snippet below. We can see that it gets EPROCESS of SYSTEM process (PID=4), and copies its privilege token to EPROCESS of current process.

Figure 1. Code snippet of the sample

From the analysis, we can see that it is easier to exploit these kernel vulnerabilities than to exploit vulnerabilities like Internet Explorer UAF vulnerabilities. Some effective protections in user-mode, like DEP, is easily bypassed in kernel-mode exploits. This is because a program, instead of entered data or script, is used to exploit the bug. Such code is by its nature already executable.

With more application sandboxing adopted in the OS, kernel vulnerabilities will be more important for privilege elevation. Though this exploitation method is not new anymore, it will be noticed by attackers, especially now that CVE-2014-4113 is public.

During our sample sourcing, we even saw that the source code of an exploit creation tool was exposed. It is expected that more exploits variants will be created by attackers. We believe that threat actors and attackers need kernel vulnerability to carry out EoP attacks and break application sandboxing. Once information about these exploitation methods become more prevalent, we may see more similar kernel zero-day vulnerabilities in the future.

Windows 7 and Windows XP are the versions of Windows most at risk of this attack. Enterprises are heavy users of both versions, and may be affected by this threat. We highly recommend that users and system administrators apply the relevant patches and keep their systems up-to-date.

Windows 8 and later versions are at less risk, as the currently available exploit code is blocked on these versions. This is because of a new security feature known as Supervisor Mode Execution Prevention (SMEP), which prevents the access (read/write/execute) of user-mode memory pages in kernel-mode.  As such, the access to null page and shell code will not lead to code execution, although it will lead to crashes.

Trend Micro is continuously monitoring the threat landscape for any developments regarding these vulnerabilities including Sandworm. For more information on them, you may read our other articles:

• Sandworm to Blacken: The SCADA Connection
• An Analysis of Windows Zero-day Vulnerability ‘CVE-2014-4114’ aka “Sandworm”
• MS Zero-Day Used in Attacks Against European Sectors, Industries