Shulou(Shulou.com)05/31 Report--

This article introduces how to achieve Microsoft local rights loophole cve-2019-1458 analysis, the content is very detailed, interested friends can refer to, hope to be helpful to you.

I. brief introduction of loopholes

This vulnerability is a local privilege escalation vulnerability in windows platform EoP (Escalation of Privilege), which is a wild 0day attack first captured by Kaspersky Lab in November 2019. The vulnerability was first publicly disclosed on December 10, 2019.

The system versions affected by this vulnerability are:

Windows Server 2012 R2 (Server Core installation), Windows Server 2012 R2, Windows Server 2012 (Server Core installation), Windows Server 2012, Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation), Windows Server 2008 R2 for x64-based Systems Service Pack 1, Windows Server 2008 R2 for Itanium-Based Systems Service Pack 1, Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation), Windows Server 2008 for x64-based Systems Service Pack 2, Windows Server 2008 for Itanium-Based Systems Service Pack 2, Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation), Windows Server 2008 for 32-bit Systems Service Pack 2, Windows RT 8.1, Windows 8.1 for x64-based systems, Windows 8.1 for 32-bit systems, Windows 7 for x64-based Systems Service Pack 1, Windows 7 for 32-bit Systems Service Pack 1, Windows Server 2016 (Server Core installation), Windows Server 2016, Windows 10 Version 1607 for x64-based Systems, Windows 10 Version 1607 for 32-bit Systems, Windows 10 for x64-based Systems, Windows 10 for 32-bit Systems.

Fix: https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1458#Security Updates

Second, the cause of loophole

The flaw occurs in windows's multi-user management driver file win32k.sys (path: C:\ Windows\ System32\ win32k.sys). When window objects are assigned certain values, win32k.sys cannot handle these objects correctly, thus triggering arbitrary memory write operations, which can be extended to arbitrary address read and write operations, and then the logged-in ordinary privilege users can be promoted to system privileges by replacing token. The cause of this vulnerability is different from the usual overflow vulnerability, but more like a logical vulnerability.

Win32k.sys file description: this component mainly provides window management and graphics device interface for the application layer. Win32k.sys registers a set of calling functions to the kernel and interferes with the running of the kernel process thread. It is the kernel implementation of user-mode components such as user32.dll, GDI32.dll and so on.

Third, loophole analysis

The following analysis is based on the windows server 2008 R2 environment, win32k.sys hash:CBEF2EB83438ED9FC39411CC8378B0E7.

The root cause of the vulnerability is that the * (gpsi+0x154) in InitFunctionTables () in win32k.sys is not initialized, which gives us the opportunity to call the undisclosed (that is, non-derived function) system function win32KroomNtUserMessageCall () and to set its Msg parameters and other conditions (see below) to bypass some of the judgment branches of the relevant function, and finally reach the target function xxxPaintSwitchWindow. The address pointers of some memory write statements in this function can be controlled by us (using the SetWindowLongPtr function), resulting in arbitrary memory read and write operations.

First, let's take a look at the function call relationship of xxxPaintSwitchWindow:

Since the ultimate exploit lies in xxxPaintSwitchWindow, let's first take a look at the tuned function relationship of xxxPaintSwitchWindow:

You can see that the xxxWrapSwitchWndProc () function serves as the entry point to the final xxxPaintSwitchWindow.

The NtUserMessageCall function call:

Then we follow win32KroomNtUserMessageCall () to look down:

Although win32KroomNtUserMessageCall () is an unexposed function, we can find information about this function on reactos.org for reference (although some functions on this site may not be exactly the same as those of the windows system, it is better to have a reference than none at all):

Looking back at the pseudo code in win32k.sys:

We can see that the second parameter Msg of NtUserMessageCall () controls the specific function executed in gapfnMessageCall []. When Msg==1, (v9-0x68001000000i64+0x2A6390) & 0x3F) = = 0x11, that is, decimal 17, and the corresponding function is NtUserfnINLPHELPINFOSTRUCT ():

We can see from NtUserMessageCall () that the NtUserfnINLPHELPINFOSTRUCT () parameter is passed from the parameter of NtUserMessageCall () (Note: we can see that some of the parameters are not shown in the parameter list of the called function, which may be due to the incorrect conversion of the pseudo code of IDA (x64 parameter transfer is saved in the stack area), which can be confirmed in the disassembly code. When we look at NtUserfnINLPHELPINFOSTRUCT (), we find that it executes to (gpsi+8i64* ((a6room6) & 0x1F) + 16):

The a6 parameter in this (gpsi+8i64* ((a6room6) & 0x1F) + 16) is controllable from the sixth parameter dwType of NtUserMessageCall (). Let's look at the array of gpsi functions (in InitFunctionTables ()):

Here we see xxxWrapSwitchWndProc (), the beginning of the exploit function call chain. So to get the program to run there, we need to make 8i64 * ((a6 + 6) & 0x1F) + 16 percent 0x40 dwType as the sixth parameter dwType from NtUserMessageCall (), which is controllable and calculates: a6percent zero or a6==0xE6, that is, the dwType of NtUserMessageCall () should be set to 0 or 0xE6.

Now that we have the control program running to xxxWrapSwitchWndProc (), let's take a look at this function:

We see that in order to execute the next function of ROP, we need the if condition to be true, so we need to go into CheckProcessIdentity () and take a look:

You can see that as long as we do not allow A1, that is, the first parameter of NtUserMessageCall () to be equal to-1, in fact, when we use NtUserMessageCall (), the first parameter is the window instance handle, which will not be-1. So CheckProcessIdentity () always returns 1, that is, xxxWrapSwitchWndProc () executes to xxxSwitchWndProc ().

OK, now it's time to go into xxxSwitchWndProc () and see how we can further execute the next ROP chain function (the rest of which is also the hardest to bypass):

As mentioned above, in the if judgment before if (v6roomroom1), * (_ WORD *) (a1+0x42) is tagWND- > fnid (the default is 0 when the user window is first created), and the latter * (_ WORD *) (gpsi+0x154) is 0, so changing if can make pass smoothly.

When we set the second parameter Msg==1 of NtUserMessageCall () to make v6 declare 1, that is, the program goes smoothly into the switch statement; then, we call NtUserMessageCall () again and set Msg==0x14 (or 0x3A) to get into our target function xxxPaintSwitchWindow ().

Well, let's take a look at xxxPaintSwitchWindow () next:

From which we can see line 36 function parameter A1 (A1 is window object) to control the value of extraWNDdata, by controlling lines 60, 61, 63, 64, we can achieve any address write operation, but only if we skip the three checks in the red box first. A1 is a window object handle, and its data structure is tagWND.

First, let's take a look at the first judgment: * (_ BYTE *) (A1 + 0x37) & 0x10, let's take a look at Win32kapptagWNDroom0x37:

The 0x10 is:

So to make the if statement true, you need the fifth bit bit 1, that is, bVisible is true, which can be achieved by setting the fourth parameter of CreateWindowEx to WS_VISIBLE. So this judgment can be pass.

Let's look at the second judgment: we need to make both sides of the "or" false. First of all, * (_ WORD *) (A1 + 0x42) has made it equal to 0x2A0 in the judgment statement of our bypass xxxSwitchWndProc () function, and 0x3FFF0&x2A0 is still equal to 0x2A0; then look at * (_ DWORD *) (A1 + 0xE8) + 0x128i64! = * (_ WORD *) (gpsi + 0x154), because (gpsi + 0x154) is not assigned, so the statement is always false. This judgment is also pass.

Finally, let's look at the third judgment: if (* (_ BYTE *) (A1 + 0x2B) & 0x80), which checks whether the bDestroyed is true, that is, whether the window has been destroyed. The window has not been destroyed, of course, pass should judge. The corresponding tagWND structure is as follows:

And extraWNDdata = * (_ QWORD *) (A1 + 0x128) we can control it through the function SetWindowLongPtr.

From the PaintSwitchWindow, you can see that lines 45 and 51 judge you for keyboard status detection, where GetKeyState () picks up the status of the specified virtual key. This state specifies whether the key is UP, DOWN, or triggered. The result > 0 indicates that the key is not pressed, and the result < 0 indicates that the key is pressed. The parameter 0x12 is a virtual key code, which represents the "ALT" key. Similarly, GetAsyncKeyState is a function used to determine the state of a specified virtual key when a function is called, and to determine whether the user is currently pressing a key on the keyboard. So we need to simulate alt and press it to pass it.

OK, now the program can reach our destination smoothly.

In addition, it is necessary to explain:

When we switch windows by setting CreateWindowEx () (the second parameter is 0x8003), we will cause the InternalRegisterClassEx () function to execute, in which the statement will cause * (gpsi+0x154) to be assigned to 0x130, so if we execute exp again, we will not be able to skip the if statement of the above xxxSwitchWndProc () function, so we will only have one chance to change exp unless the system is restarted:

2.SetWindowLongPtr () must be called after the first call to NtUserMessageCall () and before calling CreateWindowEx () to create the toggle window. This is because the first call to NtUserMessageCall () requires an extraWNDdata of 0 to skip the relevant judgment, so we cannot call SetWindowLongPtr () to set the extraWNDdata before that. Secondly, we can see inside SetWindowLongPtr () that because * (gpsi+0x154) is assigned to 0x130 after CreateWindowEx () creates the switch window, SetWindowLongPtr () does not correctly execute the branch we want it to execute in the following figure, so we need to execute SetWindowLongPtr () before CreateWindowEx () creates the switch window.

IV. POC ro EXP analysis

Debug EXP path: https://github.com/unamer/CVE-2019-1458

First of all, we use windbg to debug dual computers in kernel mode, and set the symbol path and download related symbols.

The debugging environment is the windows server 2008 R2 environment, using cmd.exe to load exp:

Cmd.exe c:\ users\ guest\ desktop\ 6source.exe whoami

First, let's use the command! process 0 to find the cmd.exe process:

Then use the command .process fffffa8032782060 to switch to the immersive cmd process

Load symbols:

Then we can set some user-state breakpoints (here I set conditional breakpoints to locate the destination address faster) to make windbg break the key points in 6source.exe:

After executing the command g, we press the enter key in windows server 2008 R2 to run the program, and then trigger the breakpoint. EXP programming is consistent with our analysis, and we skip the previous debugging process. When we enter SetWindowLongPtr () and break it, we can see that the additional data extraWNDdata of the window object is set:

Then you see the creation of the toggle window:

The second call to NtUserMessageCall () triggers a reference to extraWNDdata:

We set up to follow and stop at xxxPaintSwitchWindow ():

See that extraWNDdata is referenced:

The subsequent Token replacement process is already a more mature means, so I will not repeat it here.

Vulnerability analysis and vulnerability exploitation are of different levels. Personally, it is easier to analyze vulnerabilities, but to write vulnerabilities using EXP, you need to master some public and private function calls and certain development capabilities, especially general and robust EXP writing is at a higher level, which is based on vulnerability analysis plus vulnerability exploitation and EXP development capabilities. Of course, there are many mature techniques and methods for reference.

On how to achieve Microsoft local rights loophole cve-2019-1458 analysis is shared here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.