Guidance for CVE-2020-0796 SMBv3 Compression vulnerability patching on Azure VM

There are discussions around a new CVE coded CVE-2020-0796 that Microsoft indicated a remote code execution vulnerability found in SMBv3.1.1 compression feature. There are questions from people working on Azure environment asking me what to do.

The purpose of this article is not to dive into the vulnerability. Instead, it hopefully gives you some notes about this vulnerability especially it is targeted to deployed workloads in Azure cloud.

This article shall use several approaches that were discussed in detail here (Guidance for CVE Crypto and RDG vulnerability patching on Azure VM)

Affected Product

This vulnerability is very specific to the compression feature in SMBv3.1.1 which Microsoft implemented in Windows 10 and Windows Server build 1903 and 1909. There are many article stating that SMBv3.1.1 is vulnerable and using nmap to scan SMBv3.1.1 dialect is what those articles recommended. Again, this is not true. Nmap is helpful in identifying if the target server has port 445 (which is a common port) listening.

SMBv3.1.1 was introduced in old Windows 10 and Windows Server 2016. The following articles give you some details of SMBv3.1.1:

That said, the following products that may have compression feature in place:

  • 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)

What are affected Azure images?

As stated above, SMBv3 Compression feature is only implemented in recent Windows 10 build 1903 and 1909 so presumably all other images such as Windows Server 2016 should not be affected. Here we would need to deploy Windows 10 1903 and 1909 to see if Windows Update pulls KB4551762 which is a patch release.

Use the following script to find available Windows 10 1903 images in Azure marketplace:

$location = "West Us"
$publisherName = "MicrosoftWindowsDesktop"
$offerName = "Windows-10"
$skuName = "19h1-pro"

Get-AzVMImage -Location $location `
              -PublisherName $publisherName `
              -Offer $offerName `
              -Skus $skuName

The result gives you three OS build number:

  • 18362.592.2001092016
  • 18362.657.2002091847
  • 18362.720.2003120536

For Windows 10 1909, the offerName is 19h2-pro

  • 18363.592.2001092016
  • 18363.657.2002091847
  • 18363.720.2003120536

Based on what the KB describes two images (version 18362.720.2003120536 an 18363.720.2003120536 are believed to be vulnerable).

You can use sample template from here to deploy a Windows 10:

  • 19h1-pro: this is SKU of Windows 10 1903
  • 19h2-pro: this is SKU of Windows 10 1909

To verify if these are the only one that require the KB, deploy them and check Windows Update.

If any virtual machine that doesn’t get this KB it is likely not vulnerable. Otherwise there is still not any KB release for that OS version.

SMBv3 Compression Mitigation Check

Since the vulnerability affected SMBv3.1.1 compression feature, it is recommended to disable the feature on SMBv3 Server. You can use the the following script to disable:

#Requires -RunAsAdministrator
$parameters = @{
    Path  = "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
    Name  = 'DisableCompression'
    Type  = 'DWORD'
    Value = 0
    Force = $true
}
Set-ItemProperty @parameters

And we could base on this key value to check if the mitigation is implemented:

$releaseNumber =  (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").ReleaseId
$registry = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
$result = $releaseNumber -in (1903, 1909) -and `
          $registry.DisableCompression -eq "1" 

if ($result -eq $true) {
    Write-Host -ForegroundColor Green "[-] SMBv3 Compression has been disabled"
}

elseif ($result -ne $true) {
    Write-Host -ForegroundColor Red "[-] SMBv3 Compression hasn't been disabled"
}

Update & Patch Management

If you already have Update Management enabled you can on-board testing Windows 10 virtual machines and verify from Update Management reporting portal.

Azure Security Center would also generate a recommendation related to the KB if it is required to be installed on vulnerable virtual machine.

Desired State Configuration

If you have bunch of vulnerable virtual machines and you would want to monitor SMBv3 compression mitigation, you would need DSC. The idea is to create a compiled node configuration to check registry key DisableCompression and mark a virtual machine non-compliant if there is a required value. This article gives you sample DSC script to disable SMBv3.1.1 Compression.

You could use the following sample one and compile it in Azure Automation DSC:

configuration SmbV3CompressionMitigation {
    Import-DscResource -ModuleName PSDesiredStateConfiguration   
    Node 'localhost' {
        Script 'SmbV3CompressionMitigation' {
            GetScript  = {
            }
            TestScript = {
                $releaseNumber =  (Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").ReleaseId
                $registry = Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters"
                $result = $releaseNumber -in (1903, 1909) -and `
                          $registry.DisableCompression -eq "1" 
                return $result
            }
            SetScript  = {
            }
        }
    }

 

If you need an ARM template to be used with new virtual machine to get on-boarded to DSC node, refer to this one.

Not only Azure Automation DSC, Azure Guest Configuration Policy would be a good option in case you would want to monitor virtual machines for a specific period of time.

Network Protection

As Microsoft stated, this vulnerability can be exploited against a client, an authenticated attacker would need to convince a virtual machine to configure to use malicious SMBv3 server and connect to it. The diagram would depict the attack vector:

445 is normally open especially when you want to mount Azure File Service to a local virtual machine that requires 445 to be allowed to Azure File Service endpoint. While allowing widespread 445 outbound that may leave an opportunity for an attacker to perform a file-less attack on the target victim to talk to a malicious SMBv3 server.

From network protection perspective, you are recommended to control outbound port 445. You need to ensure your virtual machines communicate with trusted destination (host and Azure endpoint).

Reference

Again, you do need to understand that SMBv3 is not vulnerable but the compression feature is. And using nmap to scan the target wouldn’t be the way to identify this vulnerability.

Below are some great analysis write-up as well as reference materials I’d highly recommend you to read:

This entry was posted in Security Operation and tagged , , . Bookmark the permalink.

1 Response to Guidance for CVE-2020-0796 SMBv3 Compression vulnerability patching on Azure VM

  1. alan-msft says:

    It is always a great article I luckily found. I will definitely share to my customer. Thank you very much azsec!

Leave a Reply

Your email address will not be published. Required fields are marked *