Attacker Value
High
(1 user assessed)
Exploitability
Unknown
(1 user assessed)
User Interaction
None
Privileges Required
None
Attack Vector
Network
11

CVE-2020-3992 — ESXi OpenSLP remote code execution vulnerability

Disclosure Date: October 20, 2020
Exploited in the Wild
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
Initial Access
Techniques
Validation
Validated

Description

OpenSLP as used in VMware ESXi (7.0 before ESXi_7.0.1-0.0.16850804, 6.7 before ESXi670-202010401-SG, 6.5 before ESXi650-202010401-SG) has a use-after-free issue. A malicious actor residing in the management network who has access to port 427 on an ESXi machine may be able to trigger a use-after-free in the OpenSLP service resulting in remote code execution.

NOTE: VMware issued a patch for the patch on 2020-11-04. The advisory URL — https://www.vmware.com/security/advisories/VMSA-2020-0023.html — did not change.

Add Assessment

5
Ratings
Technical Analysis

This is one of a set of vulnerabilities from the Zero Day Initiative affecting VMWare products. This is the most significant and most valuable to attackers in my opinion as this affects ESXi servers which are difficult and sometimes impossible to patch, depending on the age and type of hardware. VMWare ESXi updates can be done through a VMWare vCenter server, but as those are not present in all environments, a complex, manual update may be necessary, assuming the update is compatible with the hardware. The lack of legacy support and possible manual nature of VMWare ESXi’s update process will likely increase the time-availability of this vulnerability for attackers, even in enterprise environments.
The exploit target is the OpenSLP service on port 427, open and running in a default configuration. Here is a UDP nmap scan of an affected server:

Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-20 13:05 CDT
Nmap scan report for server.redacted (xxx.xxx.xxx.xxx)
Host is up (0.00055s latency).
Not shown: 998 open|filtered ports
PORT    STATE  SERVICE
161/udp closed snmp
427/udp open   svrloc

Nmap done: 2 IP addresses (1 host up) scanned in 10.32 seconds

The service is vulnerable to a specially crafted packet that can cause a use-after-free allowing arbitrary code execution. It is important to note that in the VMWare advisory here (https://www.vmware.com/security/advisories/VMSA-2020-0023.html), they include impacted products other than ESXi, but those are for other vulnerabilities that are less severe. A good breakdown of the vulnerabilities is here: https://www.cybersecurity-help.cz/vdb/SB2020102044

I have not yet seen a PoC for this vulnerability, so it is difficult to comment on the exact difficulty for the exploit, but given the nature of ESXi servers as often critical infrastructure with access to login servers like Domain Controllers, their high uptime requirements, specialty operating system, and difficulty patching, even if the exploit were highly complex, it would still be worth it for a given attacker.

CVSS V3 Severity and Metrics
Base Score:
9.8 Critical
Impact Score:
5.9
Exploitability Score:
3.9
Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector (AV):
Network
Attack Complexity (AC):
Low
Privileges Required (PR):
None
User Interaction (UI):
None
Scope (S):
Unchanged
Confidentiality (C):
High
Integrity (I):
High
Availability (A):
High

General Information

Products

  • VMware ESXi

Exploited in the Wild

Reported by:

Additional Info

Technical Analysis

On October 20, 2020, VMware published details on CVE-2020-3992, a critical use-after-free (UAF) vulnerability in ESXi, VMware’s enterprise-class hypervisor. The vulnerability allows an attacker on the management network with access to port 427 on an ESXi machine to achieve remote code execution by triggering a use-after-free in the OpenSLP service. CVE-2020-3992 carries a CVSSv3 base score of 9.8.

On November 4, VMware updated their advisory to note that the October 2020 ESXi patches were incomplete and did not fully address the vulnerability. Two days later, Microsoft researcher Kevin Beaumont posted a warning on Twitter that a ransomware group was using CVE-2020-3992 and another ESXi vulnerability (CVE-2019-5544) to “bypass all Windows OS security, by shutting down VMs and encrypting the VMDKs directly on [the] hypervisor.”

CVE-2020-3992 is an active threat. As of November 10, 2020, there are no public exploits or proofs-of-concept (PoC).

Affected products

  • ESXi 7.0
  • ESXi 6.7
  • ESXi 6.5
  • VMware Cloud Foundation (ESXi) 4.x
  • VMware Cloud Foundation (ESXi) 3.x

Note: As of November 10, 2020, updated patches for VMware Cloud Foundation ESXi have not yet been released.

Rapid7 analysis

Use-after-free vulnerabilities are notoriously difficult to exploit reliably, and in many cases we would emphasize the lower likelihood of speedy proof-of-concept (PoC) development or widespread attacks. However, as Brendan Watters noted in his October 20 assessment of CVE-2020-3992, ESXi servers are critical infrastructure and high-value attack targets within many organizations: subject to high availability requirements, difficult to patch, and a pathway to domain controllers and other login servers. In other words, high exploit development complexity is offset by the gains of successful exploitation.

Beaumont’s Twitter post indicates that so far, a single ransomware group is attacking vulnerable ESXi servers, which may mean that the group bought an exploit on the black market. Ransomware groups profit most by attacking at scale, but we also expect that other attackers—e.g., nation state-sponsored threat actors—will add CVE-2020-3992 to their toolkits for more targeted operations. If you haven’t yet read the tweet thread on the ESXi vulnerabilities, it’s highly recommended.

Rapid7 also have a blog on this vulnerability here.

Guidance

VMware ESXi customers should update to the latest patches or mitigate the vulnerability (November 4, 2020) as quickly as possible. As a workaround, VMware customers can disable the SLP service and prevent CIM clients that use SLP from finding CIM servers over port 427. Full instructions for both enabling and removing the workaround are in VMware’s KB article here. ESXi management ports should not be exposed beyond the management network.

References