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

This article to share with you is about how to carry out Windows rights tool compatibility BUG positioning and repair, Xiaobian think quite practical, so share to everyone to learn, I hope you can read this article after some harvest, not much to say, follow Xiaobian to see it.

I. Background:

In May 2018, Microsoft released a patch for a Windows operating system kernel component vulnerability (CVE-2018-8210), which affects multiple versions of the operating system and can be successfully exploited to allow ordinary applications to execute arbitrary code with kernel privileges.

In June, the author analyzed the vulnerability and published a vulnerability analysis and exploit article (address), which also came with an authorization tool that supports WinXP, Win2003, Win7, Win2008 and other systems. Later, some netizens replied that the tool was invalid under Win7 x86 system. After debugging, it was confirmed that there were some compatibility problems with the tool. This article will supplement the explanation for this problem and solve the existing compatibility problem.

CVE-2018-8120 is a buffer overflow vulnerability that can cause kernel arbitrary address writes. The exploit tool in the previous section modifies the kernel service function pointer table by triggering the vulnerability and replacing it with a ShellCode address that modifies the current process Token.

II. Problem positioning:

After testing in Win7 x86 really can not achieve the right, now for the problem location. Set up the dual debugging kernel environment, set breakpoints at key positions, and debug to confirm the cause of the problem.

Exploit Tools Debugging

First set up the dual debugging environment, virtual machine installation Win7 x86, real machine installation WinDbg kernel debugging, win32k! SetImeInfoEx () sets a breakpoint to see if the privilege tool can successfully invoke the vulnerability function.

Confirm that SetImeInfoEx() can be successfully called, and check the SetImeInfoEx() function of this version through IDA disassembly to confirm that the vulnerability exists.

Single step trace in SetImeInfoEx() function to confirm whether vulnerability can be triggered

A buffer overflow vulnerability that triggers the SetImeInfoEx() function was found after single-step tracing, successfully modifying the specified memory data.

The exploit enables arbitrary kernel address reading and writing by overwriting key fields of GDI kernel objects. Continue with the exploit tool to check for successful modification of the kernel service function pointer table HalDispatchTable.

Further inspection revealed that the exploit calculated the HalDispatchTable memory address incorrectly, resulting in the exploit not successfully modifying the function pointer and the ShellCode not being executed.

NtQueryIntervalProfile and HalDispatchTable

Let's explain why ShellCode can be executed after modifying HalDispatchTable. NtQueryIntervalProfile() is an unexposed system call exported from Ntdll.dll. It calls the KeQueryIntervalProfile() function exported by the kernel executable ntosnl.exe. If we disassemble this function, we can see the following:

Located in NT! The function at HalDispatchTable+0x4 is called by KeQueryIntervalProfile()(see red box). So if we overwrite the pointer on that address-that is, the second pointer in HalDispatchTable-with our ShellCode address; then we call the function NtQueryIntervalProfile(), which will execute our ShellCode.

III. Problem solving:

The problem has been identified above, because there is no correct function pointer to modify the system service table, resulting in the ShellCode that is not executed. The problem now is to figure out why the original calculation went wrong and resulted in the incorrect address being calculated.

How to calculate HalDispatchTable table addresses

HalDispatchTable is exported from NT kernel file. To obtain the table address, you only need to search NT kernel file export table through GetProcAddress(). However, this function cannot search kernel module in user mode.

In our exploit tool, calculating HalDispatchTable is mainly done by the function leakHal(). Here is the flow of this function:

This function first obtains the runtime base address of the ntoskrnl.exe module through EnumDeviceDrivers(), then loads ntoskrnl.exe in user mode and searches for the export address of the HalDispatchTable table. The program subtracts the module base address from the real export address to obtain the offset value of the table relative to the module base address. Finally, use the runtime base address of ntoskrnl.exe obtained in the first step plus the offset value calculated above to obtain the memory address of the HalDispatchTable table table in the kernel.

ntoskrnl.exe of NT kernel files

NT kernel files are key components of Windows kernel, usually referred to as the executable file ntoskrnl.exe. But Microsoft loads different kernel executables depending on the number of cores currently on the CPU and the PAE on state.

As shown in the figure above, the system loads different kernel files according to the working mode of the current processor.

solutions

Because the original code did not consider the problem of Microsoft loading different versions of kernel components for CPU settings when calculating HalDispatchTable, it could not successfully modify function pointers on some systems.

Add code to detect CPU settings, judge NT kernel components loaded by kernel according to specific settings, and calculate the real memory address of HalDispatchTable. Here is the complementary code:

The DetectKernel () function was added to the original leakHal() code, which detects the CPU count and PAE on status and returns the name of the kernel component that the system may load. Subsequent programs load the kernel component according to the original process, obtain the memory address of HalDispatchTable table and modify it.

Finally, we call the NtQueryIntervalProfile() function, and our ShellCode will be executed with kernel privileges, which will be upgraded in place of Token.

The above is how to locate and repair the compatibility BUG of Windows power tools. Xiaobian believes that some knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.