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

How to carry out Windows SMB Ghost CVE-2020-0796 loophole analysis, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

I. introduction of loopholes

On March 10, 2020, Microsoft issued a Security Bulletin (ADV200005,MicrosoftGuidance for Disabling SMBv3 Compression) for CVE-2020-0796 on its official SRC, which stated that there was a remote code execution vulnerability in the client and server of the Windows SMBv3 version. At the same time, it is pointed out that the vulnerability exists in the function of MicroSoft Server Message Block 3.1.1 protocol to handle specific request packets, which can be exploited by attackers to execute arbitrary code in the target SMB Server or Client.

In the process of studying the vulnerability, Qiming Star ADLab security researchers found that there were some problems in some vulnerability analysis currently circulated, so they analyzed the vulnerability deeply and reproduced it on the Windows 10 system.

Second, the recurrence of loopholes

The Windows 10 1903 version was used for reproduction. After the vulnerability is exploited, a cmd shell with system privileges is created after the authorization of the validator is completed, as shown in figure 1.

Figure 1 CVE-2020-0796 Local Lightning

Third, the basic principles of vulnerabilities

The CVE-2020-0796 vulnerability lies in the affected version of Windows driver srv2.sys. Windows SMB v3.1.1 adds support for compressed data. Figure 2 shows the composition of SMB data packets with compressed data.

Fig. 2 SMB Datagram structure with compressed data

According to the Microsoft MS-SMB2 protocol documentation, the structure of SMBCompression Transform Header is shown in figure 3.

ProtocolId:4 bytes, fixed to 0x424D53FC

OriginalComressedSegmentSize:4 bytes, raw uncompressed data size

CompressionAlgorithm:2 bytes, compression algorithm

Flags:2 bytes, see the protocol documentation for details

Offset/Length: depending on the value of Flags, Offset or Length,Offset indicates the offset of the compressed data in the packet relative to the current structure

Figure 3 SMB Compression Transform Header data structure

Srv2DecompressData, the decompression function for processing SMBv3 compressed packets in srv2.sys, does not strictly verify the validity of the OriginalCompressedSegmentSize and Offset/Length fields in the packet. These two fields affect the parameters of the memory allocation function SrvNetAllocateBuffer in Srv2DecompressData. The Srv2DecompressData function decompiled code as shown in figure 4, and the actual argument to SrvNetAllocateBuffer is OriginalCompressedSegmentSize+Offset. These two parameters are directly derived from the fields in the SMB Compression Transform Header in the packet, and the function does not determine whether these two fields are legal or not, so it directly adds them as the parameters of memory allocation (unsigned int type).

Figure 4 key code of the Srv2DecompressData function

Here, the OriginalCompressedSegmentSize+Offset may be less than the actual amount of memory that needs to be allocated, so there is a risk of out-of-bounds reading or writing in subsequent calls to the decompression function SmbCompressionDecompress.

IV. The process of raising rights and using them

At present, the disclosed local claim exploitation for this vulnerability includes the following main processes:

(1) the verifier first creates a session connection to the SMS server (marked as session).

(2) the validator obtains the address of the privilege member in the kernel in its own token data structure (tokenAddr).

(3) the verifier sends malformed compressed data (marked as evilData) to SMB server via session to trigger vulnerabilities. EvilData contains tokenAddr, permission data, and overflow placeholder data.

(4) after receiving the evilData, SMS server triggers the vulnerability and modifies the permission data at the tokenAddr address to enhance the permissions of the verifier.

(5) after obtaining the permission, the verifier controls the winlogon to create the system user shell.

Fifth, analysis of memory allocation of vulnerabilities

First, take a look at the contents of the publicly utilized evilData packets, as shown in figure 5.

Fig. 5 SMB packet with compressed data sent by weighted poc

The content of the packet is simple, and several key fields are as follows:

OriginalSize: 0xffffffff

Offset:0x10

Real compressed data: 13 bytes of compressed data, decompressed to 1108 bytes of'A 'plus 8 bytes of token address.

SMB3 raw data: actually consists of two 8-byte 0x1FF2FFFFBC (total length 0x10) plus 0x13 bytes of compressed data

From the analysis of the above vulnerability principle, we can see that the cause of the vulnerability is the improper memory allocation caused by the lack of legitimacy judgment of the message field by the Srv2DecompressData function. In this vulnerability packet, OriginalSize is a deformed value. OriginalSize+ Offset = 0xffffffff + 0x10 = 0xf is a very small value that will be passed to SrvNetAllocateBuffer for invocation. Let's examine the memory allocation in detail. The decompiled code for SrvNetAllocateBuffer is shown in figure 6.

Figure 6 SrvNetAllocateBuffer memory allocation process

Because the parameter passed to SrvNetAllocateBuffer is 0xf, according to the processing flow of SrvNetAllocateBuffer, the requested memory will be allocated from the SrvNetBufferLookasides table. It should be noted here that the variable SrvDisableNetBufferLookAsideList is related to the registry key, and the system default SrvDisableNetBufferLookAsideList is 0.

Figure 7 SrvDisableNetBufferLookAsideList variable initialization process

The SrvNetBufferLookasides table is initialized by the function SrvNetCreateBuffer, and the actual SrvNetCreateBuffer loop calls SrvNetBufferLookasideAllocate to allocate memory. The parameters for calling SrvNetBufferLookasideAllocate are ['0x1100codes,' 0x2100codes, '0x4100codes,' 0x8100codes, '0x10100codes,' 0x20100records, '0x40100codes,' 0x80100codes, '0x100']. In this case, the memory allocation parameter is 0xf, and the corresponding lookaside table is an item of 0x1100 size.

Figure 8 SrvNetCreateBuffer decompiled code

The SrvNetBufferLookasideAllocate function actually calls SrvNetAllocateBufferFromPool to allocate memory, as shown in figure 9.

Figure 9 SrvNetBufferLookasideAllocate decompiled code

In the function SrvNetAllocateBufferFromPool, for the memory allocation size requested by the user, the internal memory allocated through the ExAllocatePoolWithTag function is actually larger than the requested value (the extra part is used to store part of the memory-related data structure). Take the request for allocating 0x1100 size as an example, after a series of judgments, the final allocated memory size is "_ size= 0x1100 + E8 + 2* (MmSizeOfMdl + 8)."

Figure 10 partial decompilation of the SrvNetAllocateBufferFromPool function

After the memory allocation is completed, the SrvNetAllocateBufferFromPool function also initializes the allocated memory and finally returns a pointer to the memory information structure as the return value of the function.

Figure 11 SrvNetAllocateBufferFromPool initializes memory data

Here we should pay attention to the following data relationship: the return value return_buffer of the SrvNetAllocateBufferFromPool function points to a memory data structure whose offset between the starting address of the memory data structure and the starting address of the actual allocated memory (the memory allocated by the function ExAllocatePoolWithTag) is 0x1150. The position 0x18 points to the actual allocated memory starting address offset from the 0x50 location, and the final return_buffer will be the return value of the function SrvNetAllocateBuffer. The memory layout relationship is shown in figure 12.

Figure 12 layout of memory data returned by SrvNetAllocateBuffer (0xf)

VI. Analysis of memory damage in vulnerabilities

Back to the vulnerability decompression function Srv2DecompressData, after memory allocation, Srv2DecompressData calls the function SmbCompressionDecompress to start decompressing the compressed data. Its functional logic is shown in figure 13.

Figure 13 Srv2DecompressData decompresses the compressed data

In fact, this function calls the Windows library function RtlDecompressBufferEx2 to decompress, and analyzes the parameters of the SmbCompressionDecompress function according to the function prototype of RtlDecompressBufferEx2.

SmbCompressionDecompress (CompressAlgo,// compression algorithm)

Compressed_buf,// points to compressed data in a packet

The size of the compressed data in the Compressed_size,// packet is calculated.

The data storage address of the decompressed UnCompressedBuf,//, * (alloc_buffer+0x18) + 0x10

UnCompressedSize,// compressed data raw size, derived from packet OriginalCompressedSegmentSize

FinalUnCompressedSize) / / data size after final decompression

As can be seen from the decompiled code, the address of the decompressed data in the function SmbCompressionDecompress is * (alloc_buffer+0x18) + 0x10. According to the analysis of the memory allocation process, alloc_buffer+0x18 points to the actual memory allocation starting location offset 0x50, so the copy destination address is the actual memory allocation starting address offset 0x60 location.

During the decompression process, the compressed data is decompressed and stored in the memory pointed to by this address. According to the construction process of evilData data, the decompressed data are occupied pit data and tokenAddr. When copied to this address, tokenAddr will overwrite the data at alloc_buffer+0x18 in the original in-memory data structure. That is, when the unzipped function SmbCompressionDecompress returns, alloc_buffer+0x18 points to the tokenAddr kernel address of the validator. The copy process is shown in figure 14:

Figure 14 decompression copy process

Figure 15 memory layout after decompression

Continue to look at the subsequent processing flow of Srv2DecompressData. After the decompression is successful, the function determines that the result of offset is not 0. If it is not 0, the memory is moved. The parameters for memory copy are as follows:

Memmove (* (alloc_buffer+0x18), SMB_payload,offset)

At this point, alloc_buffer+0x18 already points to the tokenAddr kernel address of the validator, while SMB_payload now points to the permission data in evilData, and offset is 0x10. Therefore, after this memory move is complete, the permission data will be written to the tokenAddr. This means that SMS Server successfully modified the permissions of the validator, thus realizing the rights of the validator!

Another detail to note is that during decompression, the Srv2DecompressData function determines whether the actual decompressed data size FinalUnCompressedSize is the same as the original data size OriginalCompressedSegmentSize in the packet, as shown in figure 16.

Figure 16 Srv2DecompressData checks the size of the compressed data

In theory, the actual decompressed data size is 0x1100, which is not equal to the original compressed data size 0xffffffff in the packet. Here, we should enter the process of memory release later. However, in fact, in the function SmbCompressionDecompress, the OriginalCompressedSegmentSize is assigned directly to FinalUnCompressedSize after a successful call to RtlDecompressBufferEx2. This is also one of the keys to the vulnerability's success in writing arbitrary addresses.

Figure 17 SmbCompressionDecompres assignment FinalUnCompressedSize

VII. Suggestions for bug repair

CVE-2020-0796 is a memory corruption vulnerability that can be carefully exploited to cause remote code execution, while local privilege exploitation code for this vulnerability has already occurred on the network. Here, users of the affected version of Windows are advised to protect against this vulnerability in time according to Microsoft's official vulnerability protection announcement.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.