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

Today, I will talk to you about the analysis of Microsoft SMBv3 ClientServer remote code execution CVE-2020-0796 vulnerability, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

1. 1.SMBv3 introduction of basic information about vulnerabilities

Server message Block (SMB) is a network communication protocol used to provide shared access to files, printers and serial ports on the network between nodes. It also provides an authenticated mechanism for interprocess communication. Most uses of SMB involve computers running Microsoft Windows, known as "Microsoft Windows networks" before the introduction of Active Directory. The corresponding Windows services are LAN Manager servers for server components and LAN Manager workstations for client components.

Windows 10 and Windows Server 2016 introduced SMB 3.1.1. In addition to the AES-128 CCM encryption added in SMB3, this version also supports AES-128 GCM encryption and uses SHA-512 hashes for pre-authenticated integrity checks. SMB 3.1.1 also makes security negotiation necessary when connecting to the client using SMB 2.x and later.

two。 Vulnerability description

CVE-2020-0796, Microsoft SMBv3 Client/Server remote code execution vulnerability. The vulnerability exists in the srv2.sys file. Because SMB does not correctly handle the compressed data packet, when decompressing the packet using the length passed by the client, it does not check whether the length is legal, resulting in integer overflow.

3. Vulnerability file

The vulnerability lies in the srv2.sys file.

4. Loophole function

The vulnerability involves multiple functions:

Srv2DecompressMessageAsync

Srv2DecompressData

Smb2GetHonorCompressionAlgOrder

Smb2SelectCompressionAlgorithm

Smb2ValidateCompressionCapabilities

Second, in-depth analysis of loopholes 1. Basic data structure

Let's take a look at the SMB2 COMPRESSION_TRANSFORM_HEADER structure:

First, it illustrates the scenario used by the structure: the client or server uses SMB2 COMPRESSION_TRANSFORM_HEADER when sending compressed messages. This optional header is valid only for SMB 3.1.1 Dialect.

Give a brief description of the above fields:

The field means the ProtocolId (4 bytes) protocol identifier. The value must be set to 0x424D53FC and also represented as 0xFC, "S", "M" and "B" in network order. OriginalCompressedSegmentSize (4 bytes) the size of the raw compressed data in bytes. CompressionAlgorithm (2 bytes) this field must contain one of the algorithms specified in the CompressionAlgorithms field for compressing SMB2 messages, with the exception of "NONE". Flags (2 bytes) must be one of 2 specific values Offset/Length (4 bytes) if SMB2_COMPRESSION_FLAG_CHAINED is set in the Flags field, the field must be interpreted as a length, compressing the length of a valid payload in bytes; otherwise, the field must be interpreted as an offset. The offset, in bytes, from the end of this structure to the beginning of the compressed data segment.

The algorithm specified in the CompressionAlgorithms field:

Fixed values that are optional in the Flags field:

two。 Analyze the construction and configuration of environment

Windows version: 1909, no security update patch (KB4551762) installed

Configure kernel debugging (target host): administrator privileges start powershell or cmd and execute the following command:

Bcdedit / set dbgtransport kdnet.dllbcdedit / dbgsettings NET HOSTIP: debugger IP PORT:50000bcdedit / debug on

The results are as follows:

Debugger windbg configuration:

3. Static analysis

3.1 Patch comparison

First, compare the patches before and after the security update:

Based on the information you have, focus on the Svr2DecompressData function:

You can clearly see the addition of a call to the RtlULongAdd function, which, according to previous SMB vulnerabilities, is usually added by performing some data operations and then boundary checking.

3.2 IDA decompilation to view source code

Drag the srv2.sys file into IDA, and first observe the function implementation:

1. SMB first calls the srv2roomSrv2ReceiveHandler function to receive the packet, and sets the corresponding processing function according to ProtocolId:

If it is determined that the data in the packet is compressed (ProtocolID = 0xfc4d5342), the disposal function, the Srv2DecompressMessageAsync function, is called.

2. The srv2decompressMessageAsync function will continue to call the Srv2DecompressData function:

The Srv2DecompressMessageAsync function is not a function that actually handles compressed data, but continues to call the Srv2DecompressData function to follow up and check the Srv2DecompressData function:

You can see the part of data processing in the Srv2DecompressData function: when buffer allocation is made, SrvNetAllocateBuffer is called for allocation. However, at the time of the call, there is no check on the length of OriginalCompressedSegmentSize and Offset/Length, and no security check on the sum of the two. There is an integer overflow here, and if the sum of the two is a very large value, it will be out of memory and the value will become a very small value.

3. The srv2roomSrv2DecompressData function calls the SmbCompressionDecompress function, and then calls the ntforth RtlDecompressBufferXpressLz function to perform the actual data decompression process.

The ntasking RtlDecompressBufferXpressLz function is located in ntoskrnl.exe, and what this function actually does is:

As can be seen from the above code, when decompressing the data, we first parse the smb compress protocol data packet to obtain the size of the data that needs to be decompressed, and compare it with the Origin buffer SegmentSize value previously allocated through SrvNetAllocateBuffer to confirm that its size is not greater than OriginalCompressedSegmentSize, and then copy the memory. If v21 is greater than OriginalCompressedSegmentSize, a 0xC0000242 error is returned. Because there is no length check during memory allocation in 2, if a large OriginalCompressedSegmentSize value is passed to trigger an integer overflow, v21 can set a maximum value at this time, but through the judgment of decompress size, the buffer overflow can be caused by calling qmemcpy to copy a large size.

4. Dynamic analysis

4.1 SMB2 communication flow

The communication flow of SMB2 is shown in the following figure:

What is defined by the SMB2 protocol:

Protocol negotiation (SMB2 NEGOTIATE) / / Protocol negotiation

User authentication (SMB2 SESSION_SETUP, SMB2 LOGOFF) / / user authentication

Share access (SMB2 TREE_CONNECT, SMB2 TREE_DISCONNECT) / / shared access

File access (SMB2 CREATE, SMB2 CLOSE, SMB2 READ, SMB2 WRITE, SMB2 LOCK, SMB2 IOCTL, SMB2 QUERY_INFO, SMB2 SET_INFO, SMB2 FLUSH, SMB2 CANCEL) / / File access

Directory access (SMB2 QUERY_DIRECTORY, SMB2 CHANGE_NOTIFY) / / Directory access

Volume access (SMB2 QUERY_INFO, SMB2 SET_INFO) / / Volume access

Cache coherency (SMB2 OPLOCK_BREAK) / / Cache consistency

Simple messaging (SMB2 ECHO) / / message passing

New to SMB2.1:

Protocol Negotiation (SMB2 NEGOTIATE)

Share Access (SMB2 TREE_CONNECT)

File Access (SMB2 CREATE, SMB2 WRITE)

Cache Coherency (SMB2 OPLOCK_BREAK)

Hash Retrieval (SMB2 IOCTL) / / Hash search

New to SMB3.x:

Protocol Negotiation and secure dialect validation (SMB2 NEGOTIATE, SMB2 IOCTL) / / dialect verification

Share Access (SMB2 TREE_CONNECT)

File Access (SMB2 CREATE, SMB2 READ, SMB2 WRITE)

Hash Retrieval (SMB2 IOCTL)

Encryption (SMB2 TRANSFORM_HEADER)

New to SMB3.1.1 (introduced in 1903):

Compression (SMB2 COMPRESSION_TRANSFORM_HEADER) / / supports compressed data

4.2 connection establishment process

The first is the NEGOTIATE process, where the client sends a NEGOTIATE request and the server replies with a NEGOTIATE response.

Refer to SMB2 communication pcap and official protocol documents to construct data packets

# NetBios Session ServiceNegotiate_pkt=b'\ x00' # Message TypeNegotiate_pkt+=b'\ X00\ X00\ xe6' # Length# SMB2 HeaderNegotiate_pkt+=b'\ xfe\ x53\ x4d\ x42' # ProtocolIdNegotiate_pkt+=b'\ x40\ x00' # StructureSizeNegotiate_pkt+=b'\ x00' # CreditChargeNegotiate_pkt+=b'\ x00\ x00' # ChannelSequenceNegotiate_pkt+=b'\ x00\ x00' # ReservedNegotiate_pkt+=b'\ X00\ x00' # CommandNegotiate_pkt+=b'\ X01\ x00' # CreditRequestNegotiate_pkt+=b'\ X00\ x00' # FlagsNegotiate_pkt+=b'\ X00\ X00\ x00' # NextCommand (Chain Offset) Negotiate_pkt+=b'\ X01\ X00\ X00' # MessageId Negotiate_pkt+=b'\ xff\ xfe\ X00\ x00' # ProcessIdNegotiate_pkt+=b'\ X00\ X00\ X00 # TreeIdNegotiate_pkt+=b'\ X00\ X00'# SessionIdNegotiate_pkt+=b'\ X00\ X00' Signature# Negotiate Protocol RequestNegotiate_pkt+=b'\ x24\ x00' # StructureSizeNegotiate_pkt+=b'\ x05\ x00' # DialectCountNegotiate_pkt+=b'\ X01\ x00' # SecurityModeNegotiate_pkt+=b'\ X00\ x00' # Reserved Negotiate_pkt+=b'\ x40\ x00\ x00\ x00' # Capabilities Negotiate_pkt+=b'\ x8e\ xf8\ x84' # ClientGuid Negotiate_pkt+=b'\ xe6\ x65\ xea\ x11negotiate pktnegotiations in the pktnegotiations negotiation pktnegotiations, such as' pktnegotiations'\ xb4\ xc6\ x00\ x1cnegotiatenegotiatenegotiatenegotiatepktaccounb'\ x42\ xbf\ x6a\ x9cnegotiations X00\ x00' # NegotiateContextOffsetNegotiate_pkt+=b'\ x03\ x00' # NegotiateContextCountNegotiate_pkt+=b'\ X00\ x00' # Reserved2Negotiate_pkt+=b'\ x02\ x02' # Dialect: SMB 2.0.2Negotiatenegotiatepktnegotiationb'\ x10\ x02' # Dialect: SMB 2.1negotiatenegotiatepktnegotiationb'\ x00\ x03' # Dialect: SMB 3.0 negotiate # Dialect: SMB 3.0.2 negotiatepktnegotiations\ x11\ x03' # Dialect: SMB 3.1.1Negotiatepktnegotipktnegotib'\ x00\ x00'#Negotiate Context: SMB2_PREAUTH_INTEGRITY_CAPABILITIESNegotiate_pkt+=b'\ X01\ x00 # TypeNegotiate_pkt+=b'\ x26\ x00 # DataLengthNegotiate_pkt+=b'\ X00\ X00\ x00 # ReservedNegotiate_pkt+=b'\ x01\ x00' # HashAlgorithmCountNegotiate_pkt+=b'\ x20\ x00' # SaltLengthNegotiate_pkt+=b'\ X01\ x00' # HashAlgorithmNegotiate_pkt+=b'\ xcf\ xa4\ x93\ xd0' # SaltNegotiate_pkt+=b'\ xf3\ xd1\ x41\ x8cnegotiatepktnegotiatepktnegotiationb'\ x1a\ xcb\ x36\ x4dnegotiatenegotiation pktnegotiationb'\ x9f\ x77\ x27\ x6dnegotiatenegotiation pktaccounb'\ x72\ x80\ X2b\ xf4'Negotiate_pkt+=b'\ x71\ x94\ x64\ x99 'Negotiate_pkt+=b'\ xb3\ x91\ x4b\ x7fnegotiatenegotiatepktnegotiations\ CompressionAlgorithmCountNegotiate_pkt+=b'\ xf8\ x92\ x47\ xe2'Negotiate_pkt+=b'\ X00\ x00'#Negotiate Context SMB2_COMPRESSION_CAPABILITIESNegotiate_pkt+=b'\ x03\ x00 # TypeNegotiate_pkt+=b'\ X0e\ x00 # DataLengthNegotiate_pkt+=b'\ X00\ X00\ X00 ReservedNegotiate_pkt+=b'\ X01\ x00\ CompressionAlgorithmCountNegotiate_pkt+=b'\ X00\ X00 X00\ x00\ x00\ x00NegotiateNegotiatepktExhib'\ x02\ x00' # CompressionAlgorithmId:LZ77

Note: there are 4 NegotiateContext in the traffic package captured by my test machine, in order to ensure the versatility of PoC, delete two of them which have little to do with us, so finally use 2 NegotiateContext. Note that the previous data length needs to be modified after deletion. )

Construct the SMB2 COMPRESSION_TRANSFORM_HEADER from the official documentation:

According to the previous data structure, the first few fields are constructed normally, because Flags is divided into two cases: FLAG_NONE and FLAG_CHAINED, and we choose FLAG_NONE for simplicity. For the Offset/Length field, the four bytes there when FLAG_NONE is selected represents the position offset of offset,offset from the end of the 4 bytes occupied by offset to the beginning of the next compressed data; when FLAG_CHAINED is selected, the four bytes here represent the size of the length,length after the compressed payload.

According to the structure of COMPRESSION_TRANSFORM_HEADER, the initial construction packet is as follows:

# NetBiosSmb2_crash_pkt=b'\ x00' # Message TypeSmb2_crash_pkt+=b'\ X00\ x20' # Length# SMB2 Compression Transform HeaderSmb2_crash_pkt+=b'\ xfc\ x53\ x4d\ x42' # ProtocolIdSmb2_crash_pkt+=b'\ x10\ x00\ X00' # OriginalCompressedSegmentSizeSmb2_crash_pkt+=b'\ x02\ x00' # CompressionAlgorithm LZ77Smb2_crash_pkt+=b'\ x00\ x00' # FlagsSmb2_crash_pkt+=b'\ X01\ X00\ X00\ x00' # Offset# Compressed SMB3 Data# because we do not know the internal data processing process of the algorithm at this time So feel free to debug the compressed data Smb2_crash_pkt+=b'\ x41\ x41

4.3 WinDbg dynamic debugging

1. First, set the breakpoint bmsrv2! Srv2DecompressData` under the srv2roomSrv2DecompressData function, and send the previously constructed packet:

The breakpoint is hit and the system stops at the srv2roomSrv2DecompressData function.

two。 Step by step to the srv2decompressData + 0x68 address:

At the mov rax, qword ptr [rsp+30] command, look at the contents of the rsp+30 and find that the compressed data header is constructed.

3. Continue to trace to the place where the SrvnetAllocateBuffer command is called:

As you know from the previous IDA disassembly, this function is mainly used for buffer memory allocation. The function parameters are stored in the rcx register. After static analysis and many debugging, it is found that the value stored in rcx is exactly the sum of OriginalCompressedSegmentSize and Offset. Combined with the check for OriginalCompressedSegmentSize+Offset added by the patch, it can be conceived that the vulnerability is caused by insufficient checks.

4. Follow up and analyze the SmbCompressionDecompress function:

In this function, rcx is the first parameter, which specifies the type of compression algorithm used, and rdx is the second parameter, which specifies the location where the compressed data is stored. You can see the constructed compressed data by reading the value in rdx. If we want to make an in-depth analysis of this function, we need to understand the specific implementation of the compression algorithm, but the information of the LZ77 algorithm is not very perfect and has not been rewritten yet.

At this point, the principle of the vulnerability has been clearly analyzed, as long as the construction of the sum of OriginalCompressedSegmentSize and Offset can produce integer overflow, it is possible to trigger the vulnerability.

5. PoC reproduction of crash

Modify any field value of OriginalCompressedSegmentSize and Offset in the previous PoC code to 0xffffffff, while the other field value is non-0, and send a packet for verification:

The vulnerability was successfully triggered, resulting in the blue screen of the target host and a successful PoC test.

6. EXP reappearance of local rights

On March 30th, 2020, the public local permission extraction appeared on the Internet using EXP, and the leaked EXP is an exe file, which can be directly run in the target host to achieve local permission extraction. The running result:

Instead, check out the key source code of the LPE EXP:

The EXP mainly uses the way of writing shellcode to 'winlogon.exe' to achieve the purpose of privilege elevation, while the location and pointer of shellcode are deployed by exploiting SMB vulnerabilities.

7. Updated srv2.sys file

The IDA decompilation of the updated srv2.sys file can be found that the Srv2DecompressData function is updated and some data length checks are added, which is consistent with the patch comparison information.

8. Flow analysis

The screenshot of the blue screen traffic caused by two different PoC is as follows:

First, set the Offset/Length field to ffffffff:

Second, set the OriginalCompressedSegmentSize field to ffffffff:

9. Vulnerability defense strategy

After you are familiar with the principle of the vulnerability, you can easily defend against traffic measurement by determining whether the sum of the values of the two fields is greater than 0xffffffff to trigger an integer overflow.

This vulnerability allows a remote unauthenticated attacker to execute arbitrary code with SYSTEM privileges on a vulnerable system by using SMBv3 to connect to the vulnerable Windows computer or by causing the vulnerable Windows system to initiate a client connection to the SMBv3 server.

At present, there has been a public EXP on the Internet, and Microsoft has officially released a security patch for this vulnerability. According to the analysis of Qianlimu laboratory security researchers, this vulnerability is harmful, and the vulnerability information has spread rapidly, so users are advised to install security update patches as soon as possible.

III. Scope of influence

Currently affected Microsoft versions:

Windows 10 Version 1903 for 32-bit Systems

Windows 10 Version 1903 for ARM64-based Systems

Windows 10 Version 1903 for x64-based Systems

Windows 10 Version 1909 for 32-bit Systems

Windows 10 Version 1909 for ARM64-based Systems

Windows 10 Version 1909 for x64-based Systems

Windows Server, version 1903 (Server Core installation)

Windows Server, version 1909 (Server Core installation)

IV. Suggestions for restoration

Microsoft has released a security update patch for this vulnerability. Qianlim Lab recommends that users confirm their Windows version in time and download the corresponding version security patch for update:

Https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0618

After reading the above, do you have any further understanding of Microsoft SMBv3 ClientServer remote code execution CVE-2020-0796 vulnerability analysis? If you want to know more knowledge or related content, 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.