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

In this issue, the editor will bring you about how to analyze the Bug in the Eternal Blue of the Windows XP edition. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Background

Hacking Windows 7 is no challenge, and this time I'm going to review the exploit code for the Windows XP Eternal Blue vulnerability. This Exploit has not been successful before, and I have tried various versions of patches and service packs, but this exploit code either doesn't work or makes the device blue screen. So I intend to continue to study, because FuzzBunch has too much untapped "potential".

But during a penetration test for other Windows XP devices, I had no hope for FuzzBunch, but the scary thing is that it works.

So I asked myself, why can it be used on external Windows XP devices, but not in my experimental environment? (to make a long story short: because of the difference in NT/HAL in single-core / multicore / PAE CPU, FuzzBunch's XP Payload stops running on a single-core device. )

Multiple exploit chains

Remember, there are many versions of Eternal Blue. However, FuzzBunch's exploit chain for Windows XP is very different from other versions of Exploit. For more information, please refer to DerbyCon 8.0: [slideshow] [Video].

Payload methodology

It turns out that there is no problem with the exploit code at all, but the problem is FuzzBunch's Payload.

The main phase of Shellcode performs the following activities:

1. Using KdVersionBlock technology to obtain & nt and & hal

two。 Parse some necessary function pointers, such as halfed HalInitializeProcessor

3. Restore Boot processor KPCR/KPRCB because it crashes during exploit

4. Run DoublePulsar to plant a backdoor in the SMB service

5. Restore the running state of ntasking PopProcessorIdle to its normal state.

Mononuclear branching anomaly

By setting multiple hardware breakpoints on IdleFunction and setting the offset + 0x170 to Shellcode, we will find that the installation of branches for multi-core devices is different from that for single-core devices.

Kd > ba w 1 ffdffc50 "ba e 1 poi (ffdffc50) + 0x170 political g;"

A multicore device will ask for a function pointer to halforth HalInitializeProcessor.

This function is estimated to be used to clean up the semi-crash state of KPRCB.

A single-core device cannot find halfHalInitializeProcessorDifferent547 will return a null value. Payload will not be able to continue to run, then self-destruct through data zeroing, and the ROP chain will be set up to free some memory and resume the execution process.

Root cause analysis

The Shellcode function sub_547 fails to find the address of halfHalinitializeProcessor on a single-core CPU host, causing the execution of Payload to be forcibly terminated. Therefore, we need to reverse analyze the Shellcode function to find the root cause of the failure of the attack Payload.

A problem with kernel Shellcode here is that it doesn't take into account all the different types of NT kernel executables available on Windows XP. For example, NT programs for multi-core devices (such as ntkrnlamp.exe) can work, but single-core devices (such as ntoskrnl.exe) can have problems. In addition, halmacpi.dll and halacpi.dll have similar problems.

NT is confused

The first thing sub_547 does is to get the HAL import function used by the NT program. Payload first reads the 0x1040 offset in the NT program to find the HAL function.

In multicore Windows XP devices, reading this offset address allows Shellcode to find the correct haloghalQueryRealTimeClock function:

But there is no HAL import table on a single core device, only a string table:

At first I thought I had found the root of the problem, but it wasn't, because there was a correction code problem. Shellcode checks whether the value of the offset 0x1040 is within the HAL range. If the condition is not met, the 0xc40 is subtracted and the search is performed within the HAL address range with 0x40 as an increment until the search address reaches 0x1040 again.

Eventually, the Payload on the single core device will find a HAL function, halted HalcalibratePerformanceCounter:

Digression: formula (international famous hacker organization) is very good at judging different types of XP NT!

HAL variable byte table

After Shellcode finds the HAL function, it tries to locate the halogenated HalinitializeProcessor. The table built into Shellcode (at the 0x5e7 offset) contains a field of 1 byte length, which can be followed by a sequence of bytes. Next, Shellcode searches for the new HAL function address by traversing the incremental 0x20 bytes.

Here are the 5 bytes of target data found in the multicore version of HAL:

However, the single-core version of the HAL function is very different:

There is a similar mov instruction, but it is not a movzx instruction. Because the byte sequence is not included in this function, the code cannot find the target function.

As we all know, in different versions of Windows systems, it is not easy to identify functions by searching byte sequences. At least one thing we should learn from this vulnerability is that Exploit developers must be careful when designing exploit code and pay attention to the differences between NTOSKRNL and HAL in single-core / multi-core / PAE architecture.

The above is the editor for you to share how to analyze the Windows XP version of Eternal Blue in the Bug, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to 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.