Microsoft CVE-2020-0796 analysis.

Update on CVE-2020-0796

Alpha Team researchers have continued tracking CVE-2020-0796 since the last update. Microsoft has since released a patch and more details on the vulnerability after the disclosure of the vulnerabilities existence earlier in the week.

Vulnerability Details

On March 12th, Microsoft released details for CVE-2020-0796 here. Specific versions of Windows 10 and Windows Server were acknowledged to be vulnerable. The oldest version of Windows the flawed code was present in was released in April 2019. Microsoft disclosed the vulnerability and cited their internal research with the discovery of the bug.

Recommendations

• Apply patches. Microsoft has released a patch addressing this vulnerability. Details can be found here.
• If patching is delayed apply workarounds for disabling SMBv3 compression.
• Restrict SMB access. Disable ports 445/TCP, 137-138/UDP, 139/TCP on boundary devices.

Analyst Insight

Due to the nature of the vulnerability and the problems with disclosure, it was theorized by security researchers this could be a “wormable” remotely exploitable vulnerability along the same lines as Eternal Blue. The released patches point to a flawed SMBv3 being fixed, and there are only two versions of Windows that are currently listed as vulnerable. This significantly reduces the likely victims and how successful a worm would be.

Technical Analysis

In order to provide technical analysis, our team had to first find the bug. With vague and incomplete details from Microsoft we were able to extract a clue that helped zero-in on where the flaw is. Microsoft’s advisory stated the vulnerability was in SMBv3.1.1. While SMB is common on all modern Windows platforms, versions have mostly been limited to version 1 or 2. According to the SMB Wikipedia page, SMB version 3.1.1 is fairly new and is only supported on Windows 10 and Windows Server 2016. Microsoft makes VMs of their operations systems and applications available to download here. A reverse engineer with experience on Windows can find that the implementation of SMB is handled by a driver named srv2.sys that is located in C:\Windows\System32\Drivers.

Figure 1. A search of srv2.sys on a Windows 10 test system.

Figure 2. The file properties of the srv2.sys driver we are interested in.

Additional information from the Microsoft advisory pointed to the vulnerability being in the compression code used for SMB payloads. Compression is a fairly recent addition to SMB usage as Microsoft attempts to reduce network packet size as much as possible. Microsoft has published detailed information about their protocol design and usage. The documents here show the implementation in SMBv2 and SMBv3, giving us additional information to search srv2.sys.

Figure 3: Filtering defined strings in srv2.sys for the term “ompr.”

To actually dig into the intervals of srv2.sys we use a publicly available decompiler/disassembler called (Ghidra.)[https://ghidra-sre.org/] A simple string search for “ompress” shows a number of locations that provide a start for analysis. After working through several pivots, we find a buffer allocation called SmbCompressionDecompress.

Figure 4: A function identified to likely be exploitable by CVE-2020-0796

Of the feasible locations found in the binary, this seems the most likely candidate based on the allocation of a memory buffer immediately before compression-related code. If we can trace the origins of arguments passed to SrvNetAllocateBuffer, we can tell if a malformed packet could influence the size of memory allocated. Ideally, we would be able to tell if the size of the buffer can be forced to be too small for the decompression output, which would allow for writing past the buffer boundaries.

Next, we will craft packets using a tool called Impacket to allow for easy generation of the complex data structures used in SMB communications.

As this work was underway, Microsoft dropped a patch for the vulnerability, unannounced. With the patch now available, we could quickly verify that the fixes were in srv2.sys. Comparing the patched version of srv2.sys and the non patched version, the differences added are extremely easy to spot.

Figure 5: A patch diff of srv2.sys with the unpacthed version on left and patched version on right.

The figures above compare the unpatched version on the left to the patched version on the right. In the patched version, additional code has been added to the patched version to do additional input validation on data being passed to SrvNetAllocateBuffer.

The vulnerability is in the math used to set the size of the buffer. Due to how the values are used by the application, a negative sized buffer can be requested by a remote unauthenticated user. Just using this information, modification of the Impacket example smbclient allows for a Denial-of-Service (DoS) in less than 10 minutes of testing.

Additional steps are required to turn the DoS into a Remote Code Execution vulnerability Within a day of the patch we observed publicly available tools that replicated the DoS. At the time of publication, Alpha Team has observed no publicly available RCE tools.

Research and Exploitation

A Proof-of-Concept analyzed by Alpha Team shows that code to produce a Denial of Service against vulnerable machines is publicly available. Alpha Team has a medium confidence Remote Code Execution can be achieved.

Internet scanning data analyzed by Alpha Team shows some activity related to CVE-2020-0796 but not in any significant numbers. Internet traffic analysis done by Alpha Team shows a little over 400 IPs searching for this vulnerability 4 days after the patch was released. For comparison, in the 4 day period after EtneralBlue was released 261k IPs were scanning for indicators that would indicate if a targeted box was vulnerable.