Exploit Analysis Dianti.A
Recently we wrote about a set of detected vulnerabilities in Windows, which were used by attackers in targeted attacks, before the release of the corresponding fix by Microsoft (0day). One of these vulnerabilities in the OLE Package manager (Packager.dll) component was added to our databases as Win32 / Exploit.CVE-2014-4114.A by virus analysts. Attackers could exploit this vulnerability through a specially crafted PowerPoint presentation document with an OLE object embedded there.
In this post we would like to highlight another vulnerability from this list. This vulnerability was assigned an identifier CVE-2014-4113 and it is present in the win32k.sys driver of all supported versions of Windows (2k3 +). Vulnerability allows unauthorized (bypassing the limitations of the OS) to execute the kernel mode code and raise the privileges of the application launched by the exploit to the maximum possible level (SYSTEM). CVE-2014-4113 was closed by updating MS14-058 as part of the October patch tuesday, and the 64-bit version of the exploit was added to the database as Win64 / Dianti.A .
')
Win32k.sys itself over the past few years has been a real treasure to search for vulnerabilities like Elevation Of Privilege (or Local Privelege Escalation, LPE). In our report for 2013, it was noted that this component of the OS ranks second in the number of vulnerabilities corrected for it for the whole year. It is only ahead of the product Internet Explorer, which consists of a large number of executable files, while in the case of win32k.sys there is only one file.
Win32k.sys itself has already been written more than once, it is that part of the Windows subsystem that runs in kernel mode and is responsible for the logic and mechanisms associated with the implementation of the Windows GUI interface and its interaction with the user through input devices. In the distant past, when Windows NT was only turning into what history remembered as Windows 2000 (NT 5.0), Windows XP (NT 5.1), etc., and now Windows 10 (NT 6.4), the entire GUI subsystem worked in user mode and required a large overhead of process context switches when performing operations on screen display, processing keyboard messages, etc.
Then in NT 4.0, the win32k.sys kernel mode driver appeared to improve performance and reduce the overhead of context switches. The logic of the GUI-subsystem was divided into the part that works in user mode (known libraries user32.dll and gdi32.dll) and part of the kernel mode in the form of the win32k.sys driver. Perhaps this is why so many bugs are covered in win32k.sys, the driver code could be copied from user mode libraries in places. In addition, driver functions that should return pointers were implemented in such a way that they could also return constants, i.e. values that could not be interpreted as pointers.
Windows allows you to execute kernel-mode code only through special mechanisms (API), since such code is provided with full access to all software and hardware resources of the OS. Vulnerabilities of win32k.sys somehow allow attackers to bypass these restrictions and execute kernel mode code through an exploit.
In the case of CVE-2014-4113, the point is that you can create a special system structure for win32k ( win32k! Tagwnd ), project it into kernel mode and force one of the driver's functions to call a callback from this generated structure. The vulnerability itself lies in the fact that one of the driver functions ( xxxHandleMenuMessages ) does not check the value returned by the other function ( xxxMNFindWindowFromPoint ) (the expected pointer), and passes it on to another function ( xxxSendMessage ) that operates on the wrong value. See blog.trendmicro.com/trendlabs-security-intelligence/an-analysis-of-a-windows-kernel-mode-vulnerability-cve-2014-4113 .
32-bit version
In the case of the 32-bit version of the exploit, it uses an integer overflow argument, which is passed to the xxxSendMessage function from xxxHandleMenuMessages . This argument itself can be interpreted by the xxxHandleMenuMessages function as a pointer or as a negative value in case of an error, which is returned by the xxxMNFindWindowFromPoint function. Due to the lack of a negative value (error) check in xxxHandleMenuMessages , this function passes this value instead of the pointer to xxxSendMessage .
In general, the exploit applies the following steps to exploit.
Thus, preparation for operation is reduced to the following function.
Fig. Preparing for the exploitation of the vulnerability on a 32-bit system. To allocate an address on a zero page, the already popular ZwAllocateVirtualMemory call is used , to which one is passed as the address, which leads to a page alignment of the reserved address to zero. This “feature” has been closed for Windows 7 by updating MS13-031 , and in Windows 8+ this update is enabled by default. At the beginning of the function, the non-exported user32! PtiCurrent function is called , which returns a pointer to the Win32ThreadInfo structure. This pointer will be used to initialize the win32k! _THRDESKHEAD.pti structure field.
64-bit version
In a 64-bit virtual address space, instead of integer overflow, the exploit uses memory allocation at a given address in memory. That is, the returned constant itself is used as an address when reserving a page of memory that will be filled with the fnFillmalicioustagWnd function (see the screenshot below).
Fig. This is the structure of tagWND on Windows 7 x64. Red is the pointer to the callback function, which will point to the shell code.
Fig. The shellcode function itself, which replaces the pointer to the access token for the current process EPROCESS.
Fig. The function of creating a fake tagWND structure. To fill the first field of the structure, use the received pointer ( user32! PtiCurrent ) on Win32ThreadInfo.
Fig. Part of the fnPrepareExploitation function. On x64, a memory page is reserved by the pointer of the returned constant, i.e. 0xFFFFFFFB.
After the end of the preparatory activities, the exploit enters the exploitation stage, i.e., creates conditions for the vulnerability to trigger. To do this, use various manipulations with the menu controls and setting window traps, which ultimately causes the vulnerable function win32k to return a constant instead of a pointer. Then the process is created using the CreateProcessA function.
Fig. As a result of the exploit, the child command line process inherited its system access token.
It is worth noting that the exploitation of this vulnerability is not possible on Windows 8+ x32 & x64. In the 32-bit version, protection against allocating memory by the null pointer is present by default, and in the 64-bit version, execution of code in kernel mode from a page in user mode will be blocked by the SMEP mechanism.
In this post we would like to highlight another vulnerability from this list. This vulnerability was assigned an identifier CVE-2014-4113 and it is present in the win32k.sys driver of all supported versions of Windows (2k3 +). Vulnerability allows unauthorized (bypassing the limitations of the OS) to execute the kernel mode code and raise the privileges of the application launched by the exploit to the maximum possible level (SYSTEM). CVE-2014-4113 was closed by updating MS14-058 as part of the October patch tuesday, and the 64-bit version of the exploit was added to the database as Win64 / Dianti.A .
')
Win32k.sys itself over the past few years has been a real treasure to search for vulnerabilities like Elevation Of Privilege (or Local Privelege Escalation, LPE). In our report for 2013, it was noted that this component of the OS ranks second in the number of vulnerabilities corrected for it for the whole year. It is only ahead of the product Internet Explorer, which consists of a large number of executable files, while in the case of win32k.sys there is only one file.
Win32k.sys itself has already been written more than once, it is that part of the Windows subsystem that runs in kernel mode and is responsible for the logic and mechanisms associated with the implementation of the Windows GUI interface and its interaction with the user through input devices. In the distant past, when Windows NT was only turning into what history remembered as Windows 2000 (NT 5.0), Windows XP (NT 5.1), etc., and now Windows 10 (NT 6.4), the entire GUI subsystem worked in user mode and required a large overhead of process context switches when performing operations on screen display, processing keyboard messages, etc.
Then in NT 4.0, the win32k.sys kernel mode driver appeared to improve performance and reduce the overhead of context switches. The logic of the GUI-subsystem was divided into the part that works in user mode (known libraries user32.dll and gdi32.dll) and part of the kernel mode in the form of the win32k.sys driver. Perhaps this is why so many bugs are covered in win32k.sys, the driver code could be copied from user mode libraries in places. In addition, driver functions that should return pointers were implemented in such a way that they could also return constants, i.e. values that could not be interpreted as pointers.
Windows allows you to execute kernel-mode code only through special mechanisms (API), since such code is provided with full access to all software and hardware resources of the OS. Vulnerabilities of win32k.sys somehow allow attackers to bypass these restrictions and execute kernel mode code through an exploit.
In the case of CVE-2014-4113, the point is that you can create a special system structure for win32k ( win32k! Tagwnd ), project it into kernel mode and force one of the driver's functions to call a callback from this generated structure. The vulnerability itself lies in the fact that one of the driver functions ( xxxHandleMenuMessages ) does not check the value returned by the other function ( xxxMNFindWindowFromPoint ) (the expected pointer), and passes it on to another function ( xxxSendMessage ) that operates on the wrong value. See blog.trendmicro.com/trendlabs-security-intelligence/an-analysis-of-a-windows-kernel-mode-vulnerability-cve-2014-4113 .
32-bit version
In the case of the 32-bit version of the exploit, it uses an integer overflow argument, which is passed to the xxxSendMessage function from xxxHandleMenuMessages . This argument itself can be interpreted by the xxxHandleMenuMessages function as a pointer or as a negative value in case of an error, which is returned by the xxxMNFindWindowFromPoint function. Due to the lack of a negative value (error) check in xxxHandleMenuMessages , this function passes this value instead of the pointer to xxxSendMessage .
In general, the exploit applies the following steps to exploit.
- Using the function ntdll! ZwAllocateVirtualMemory allocates a page of memory at the zero address.
- On this page, it creates a fake win32k! Tagwnd structure , initializing a pointer to an exploit callback function (shellcode).
- Creates a condition for triggering a vulnerability, that is, passing an invalid argument (0xfffffffb, -5) to the xxxSendMessage function, which leads to an integer overflow during pointer dereferencing and memory access on a zero page. That is, when the xxxSendMessage function is accessed to the pointer field to the callback function, an overflow occurs (0xfffffffb + 0x60) of the intended address and as a result, the function will receive a pointer to the shell code.
- As a result of operation, the control receives a shell code that rewrites a pointer to the access token in the structure of the current process's EPROCESS kernel object so that it points to the access token of the system process. Later this will lead to the fact that the process created by the exploit will inherit the system process access token and gain maximum privileges in the system.
Thus, preparation for operation is reduced to the following function.
Fig. Preparing for the exploitation of the vulnerability on a 32-bit system. To allocate an address on a zero page, the already popular ZwAllocateVirtualMemory call is used , to which one is passed as the address, which leads to a page alignment of the reserved address to zero. This “feature” has been closed for Windows 7 by updating MS13-031 , and in Windows 8+ this update is enabled by default. At the beginning of the function, the non-exported user32! PtiCurrent function is called , which returns a pointer to the Win32ThreadInfo structure. This pointer will be used to initialize the win32k! _THRDESKHEAD.pti structure field.
64-bit version
In a 64-bit virtual address space, instead of integer overflow, the exploit uses memory allocation at a given address in memory. That is, the returned constant itself is used as an address when reserving a page of memory that will be filled with the fnFillmalicioustagWnd function (see the screenshot below).
Fig. This is the structure of tagWND on Windows 7 x64. Red is the pointer to the callback function, which will point to the shell code.
Fig. The shellcode function itself, which replaces the pointer to the access token for the current process EPROCESS.
Fig. The function of creating a fake tagWND structure. To fill the first field of the structure, use the received pointer ( user32! PtiCurrent ) on Win32ThreadInfo.
Fig. Part of the fnPrepareExploitation function. On x64, a memory page is reserved by the pointer of the returned constant, i.e. 0xFFFFFFFB.
After the end of the preparatory activities, the exploit enters the exploitation stage, i.e., creates conditions for the vulnerability to trigger. To do this, use various manipulations with the menu controls and setting window traps, which ultimately causes the vulnerable function win32k to return a constant instead of a pointer. Then the process is created using the CreateProcessA function.
Fig. As a result of the exploit, the child command line process inherited its system access token.
It is worth noting that the exploitation of this vulnerability is not possible on Windows 8+ x32 & x64. In the 32-bit version, protection against allocating memory by the null pointer is present by default, and in the 64-bit version, execution of code in kernel mode from a page in user mode will be blocked by the SMEP mechanism.
Source: https://habr.com/ru/post/241003/
All Articles