CVE-2020-0796 – A Potential SMB Attack in the Horizon
Principal Security Architect
April 15, 2020
Server Message Block or SMB is a protocol used extensively by windows. It allows windows computers to communicate, locate file servers, locate and communicate with windows networks services and even communicate with other operating systems that understand the SMB protocol. The latest version of SMB is SMB version 3 which is affected.
Over the years numerous vulnerabilities were discovered in the protocol which were actively exploited and used by malware authors to build ransomware, cryptominers, SCADA malware etc. MS08-067 saw the rise of the Conficker worm, MS10-061 was used by the infamous Stuxnet malware and MS17-061 was used by ransomware’s like WannaCry. These are just known popular cases, but these bugs were actively used by other threat actors too. Apart from these code execution bugs, some inherent weaknesses in the protocol also lead to downgrade attacks, relay attacks and an attack class called pass-the-hash attack.
We now seem to have a new vulnerability, CVE-2020-0796, that might offer threat actors a new way to cause damage in the near future. The vulnerability information was inadvertently published by vendors subscribed to the Microsoft MAPP service. However, the patch for this vulnerability was not released this Tuesday. Instead Microsoft released an emergency patch released on a later day[3].
CVE-2020-0796 Patch Analysis
In this analysis we will identify which function is affected by this CVE, locate where the issue is and analyze it inside windbg. Performing a binary diff of unpatched srv2.sys (version 10.0.18362.329) and the patched srv2.sys (version 10.0.18362.720) we can quickly identify the function that was modified by looking at the matched functions with very low similarity. As shown in the figure below the one that stands out is “Srv2DecompressData”
This function is a small one and one of the code blocks that stands out as interesting is the call to SrvNetAllocateBuffer. These are locations where overflows can happen. The call graph from bindiff, for the unpatched function is shown in the next figure. We see an addition of two register, which we will investigate in the next section, which is used as one of the parameters to SrvNetAllocateBuffer.
In the patched version of Srv2DecompressData before SrvNetAllocateBuffer is called there is a call to RtlUlongAdd, which performs a safer addition of two unsigned numbers with checks in place for integer overflow. From this we know that the issue is an integer overflow, that is being fixed by this patch.
CVE-2020-0796 Trigger
The SMB protocol initiates its operation with an “SMB Negotiate Protocol Request”. In this packet exchange the protocol dialects and any other extra capabilities are negotiated by the client. The client can also negotiate choice of compression algorithms in SMBv3 via a “Negotiate Context” field with Type ID 3, highlighted in grey in packet number 6 in the figure below.
Most fields in the Type 3 Negotiate Context request are self-explanatory. The last field labelled “Unknown” is a collection of fields containing the code for the compression algorithms the client is requesting be used during communication. The server responds with an “SMB Negotiate Protocol Response”. The response packet from the server has a “Negotiate Context” field with Type ID 3. This is highlighted in the figure below in packet no 7. The “Unknown” field contains the algorithms the server supports.
Once a compression algorithm has been decided by the client and server, they can choose to have data compressed and, in such cases, uses an SMB compression transform header which starts with the protocol id “\xfcSMB”. Please look at reference [4] to understand the header format. The fields “OriginalCompressedSegmentSize”, “Flags” and “Offset/Length” are of interest. Using our in-house developed PoC and varying the OriginalCompressedSegmentSize and Offset/Length field we were able to overflow the addition shown in the unpatched version of srv2.sys. We had the OriginalCompressedSegmentSize field set to 0x123 and the Offset/Length field set to 0xfffffeed. This was followed by 321 bytes of junk data. On running the PoC against a target to which windbg was attached with breakpoint enabled on Srv2DecompressData, the following was observed.
The registers rax and rcx has been set to the values we choose for our PoC and the addition overflows and results in a value 0x10 in ecx, which is a parameter to the SrvNetAllocateBuffer. Inside the function SrvNetAllocateBuffer an undersized memory is allocated from the kernel pool which eventually gets overflowed and leads to a crash.
The overly large value for the Offset/Length field leads to invalid memory reference as per the bug analysis by windbg.
As per the Microsoft advisory the vulnerability affects both server and client operating systems which uses SMB dialect 3.1.1. Microsoft has released a patch[3] and Advisory[1] on this Vulnerability. Versa VOS™ (formerly FlexVNF) IPS module detects this Vulnerability and prevents them from being connected onto the system. Versa Network’s security research team is constantly monitoring the internet for evolving threats and released the detection rule to detect this Vulnerability and will advise customers to regularly update their Database.
Download Whitepaper
References
- https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/adv200005
- https://www.helpnetsecurity.com/2020/03/11/cve-2020-0796/
- https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2020-0796
- https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/1d435f21-9a21-4f4c-828e-624a176cf2a0
