How to chain SMBleed and SMBGhost to get RCE in Windows 10

Think like an attacker, act like a defender.

That’s the pentesters’ mantra, if you ask me.

That’s why today we’re diving into one of the most interesting tactics that malicious actors use: vulnerability chaining.

To make this both practical and relevant to the current context, we’ll explore a critical vulnerability in the Server Message Block (SMB) protocol that affects multiple versions of Windows 10 and Windows Server products.

This vuln allows attackers to dump the uninitialized kernel memory of the targets. By chaining SMBleed (CVE-2020-1206) vulnerability with SMBGhost (CVE-2019-0796), it’s much easier to achieve Remote Code Execution.

1. Vulnerability Overview

What is SMBleed?

You can think of SMBleed (CVE-2020-1206) as SMBGhost’s little sister because they share the same root cause – the way SMB protocol handles the decompression of client-supplied data.

Specifically, the vulnerability occurs in the Srv2DecompressData function within the srv2.sys SMB driver. That function was also the reason for the discovery of SMBGhost.

Alongside with the compressed data, the client can set the OriginalCompressedSegmentSize header, which is responsible for indicating the space that must be allocated for the decompression process. If you send a value that exceeds the required size (but not by much!) for the decompressed data, it’ll be populated with uninitialized kernel memory data.

Here’s the vulnerable source code:

NTSTATUS Srv2DecompressData(PCOMPRESSION_TRANSFORM_HEADER Header, SIZE_T TotalSize) {
    PALLOCATION_HEADER Alloc = SrvNetAllocateBuffer((ULONG)(Header->OriginalCompressedSegmentSize + Header->Offset), NULL);
    If (!Alloc) {
       return STATUS_INSUFFICIENT_RESOURCES;    
    }    
    ULONG FinalCompressedSize = 0;  
    NTSTATUS Status = SmbCompressionDecompress(Header->CompressionAlgorithm, (PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER) + Header->Offset, (ULONG)(TotalSize - sizeof(COMPRESSION_TRANSFORM_HEADER) - Header->Offset), (PUCHAR)Alloc->Ueader->OriginalCompressedSegmentSize, &FinalCompressedSize);
    if (Header->Offset > 0) {
        memcpy(Aeader->Offset);
    }
    Srv2ReplaceReceiveBuffer(some_session_handle, Alloc);
    return STATUS_SUCCESS;
}

SMBGhost was based on the same technique, but you had to send a large OriginalCompressedSegmentSize header value to trigger a buffer overflow that enabled attackers to execute code outside the buffer boundaries.

Which are the “bleeding” versions?

You can exploit the SMBleed vulnerability in Windows 10 and Windows Server versions 1903, 1909, and 2004.

Affected versions include 1903 and 1909 starting with OS Build 18362.720 (KB4551762), respectively 18363.720 (KB4551762) and below. However, versions before KB4551762, excluding it, are also vulnerable to SMBGhost, so chained exploitation can be possible.

Besides, you can abuse version 2004 before OS Build 19041.329 (KB4557957), excluding it, through the SMBleed vulnerability.

How to find systems affected by SMBleed

In order for a target to be vulnerable, it must have the SMBv3.1.1 protocol running and the compression function enabled, which is on by default. Nowadays, the SMB service for most Windows machines is unlikely to be exposed to the Internet, so you’d commonly find this vulnerability in internal networks, most likely abused to perform lateral movement.

Let’s take a look at Shodan for possible affected devices with SMB protocols exposed to the Internet, which are also running the vulnerable OS versions that we just mentioned.

We collected the results after running some sample queries. As you can see, a large number of devices are likely to be vulnerable to SMBleed.

(Possible 17,521 affected Windows 10 Home devices – version 1903)

(Possible 11,517 affected Windows 10 Pro devices – version 1903)

(Possible 7,025 affected Windows 10 Home devices – version 1909)

(Possible 11 affected Windows 10 Education devices – version 2004)

After selecting the appropriate targets or deciding to check your own hosts, you can initiate a scan using our SMBGhost Vulnerability Scanner. If a system is affected by SMBGhost, it will be automatically vulnerable to SMBleed too!

2. Exploit overview

Pop the Kernel memory with SMBleed

The issue was discovered by ZecOps Research Team, and they also released a public PoC. You can use the PoC to exploit the SMB service with an especially crafted WRITE message to get your hands on the Windows uninitialized kernel memory leaked to an output file. However, it requires valid authentication and access to a network share on the target machine.

Hit RCE with SMBleed + SMBGhost (SMBleedingGhost)

There’s also another open-source exploit that combines the SMBleed and SMBGhost vulnerabilities to achieve unauthenticated Remote Code Execution, originally named SMBleedingGhost.

Top tip: Before you start running the SMBleedingGhost exploit, you’ll need to find the target’s offsets, which are the same for each version in particular.

For example, if you have two Windows 10 Home machines with the OS Build 18363.720 (version 1909), they will share the same offsets. This means you have to play a little “guessing” game before achieving Remote Code Execution.

To find the offsets of a specific Windows version, run this script on the running instance. After that, you will have to edit the SMBleedingGhost exploit by modifying the values defined through the “OFFSETS” array at the beginning of the code. Here’s how:

OFFSETS = {
    ‘srvnet!SrvNetWskConnDispatch’: value,
    ‘srvnet!imp_IoSizeofWorkItem’: value,
    ‘srvnet!imp_RtlCopyUnicodeString’: value,
    ‘nt!IoSizeofWorkItem’: value,
    ‘nt!MiGetPteAddress’: value
}

Where the value is a hexadecimal address in the following format: 0x*****

To make your work easier, we determined some offsets for Windows 10 (version 1909) various OS Builds:

Notice the only offsets that change are IoSizeofWorkItem and MiGetPteAddress. So, if you want to target a Windows 10 version 1909, you have to “play” with those two.

You can also brute-force those values easily, so there would be 165  or 166 >possibilities per offset.

3. How to fix these notorious SMB vulnerabilities: SMBleed and SMBGhost

The most effective and recommended solution is to apply the official Microsoft patches. Update with KB4560960 or later for versions 1903 and 1909 and KB4557957 or later for version 2004.

For those who, for objective reasons, cannot update their machines, there are also other workarounds available.

The quickest one is to disable the SMBv3 Server compression functionality which you can do by opening PowerShell and entering this command:

Set-ItemProperty -Path
"HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
DisableCompression -Type DWORD -Value 1 -Force

This won’t have any negative impact and you don’t even have to reboot the host. It will only prevent exploitation against the SMB server, leaving your SMB clients still vulnerable.

Another solution you can apply is to restrict the SMB service – which runs by default on port 445 – to the machines that need access to it. You can do this by using a whitelist approach through the firewall, which will drop any packet that tries to enter that port, except the ones originating from the allowed machines.

4. Why fixing SMBleed and SMBGhost matters

The more notorious and pervasive a vulnerability is, the more attractive it will be for attackers.

This means pentesters and other security specialists like yourself have to get creative with not only finding these vulnerabilities but also anticipating how malicious actors might exploit them.

Vulnerability chaining enables them to gain access with the handiest exploit and then move deeper into the network.

That’s why it matters you do recon before they do and patch your exposed endpoints before they have a chance to test your reactions.