Thousands of Vulnerable VMWare vCenter Servers Still Publicly Exposed (CVE-2021-21985, CVE-2021-21986)
Background
On May 25th, 2021, VMWare released patches to address VMSA-2021-0010, a critical security advisory for VMWare vCenter Server addressing two vulnerabilities. One of them was a remote code execution (RCE) in the vSphere Client (CVE-2021-21985) that exists due to a lack of input validation in the Virtual SAN Health Check plug-in, which is enabled by default in the vCenter Server. Any attackers with access to the network may exploit this vulnerability and execute commands with unrestricted privileges. The other one (CVE-2021-21986) is an authentication mechanism issue in vCenter Server plug-ins like Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager, and VMware Cloud Director Availability. As per VMWare’s advisory, the following versions are affected.
Affected Versions
- vCenter Server 6.5.0 before 6.5.0 build 17994927
- vCenter Server 6.7.0 before 6.7.0 build 18010531
- vCenter Server 7.0.0 before 7.0.2 build 17958471
- Cloud Foundation vCenter Server 3.x before 3.10.2.1 build 18015401
- Cloud Foundation vCenter Server 4.x before 4.2.1 build 18016307
Using Shodan for recon
vCenter Server is a centralized management utility to manage virtual machines, ESXi hosts, and other dependent components. vCenter Server is used by many companies to manage their infrastructure making it a possible attack initiation point. VMWare mentioned that these issues needed immediate attention in their blog so we decided to review Shodan for a quick analysis on the number of vCenter Server instances directly connected to the Internet that are vulnerable to these flaws based on their self-reported version. This data was pulled from Shodan on May 31st, just six days after the public disclosure and patch were released.
On Shodan, there are 5,271 instances of VMWare vCenter Server that are directly connected to the Internet (Figure 1)
Figure 1: Total number of VMware vCenter Servers found on Shodan
The majority of these instances are running versions 6.7.0, 6.5.0, and 7.0.x. (Figure 2)
Figure 2: Top 10 versions of the VMware Center Server on Shodan
Other stats show that top ports are probably using SSL/TLS, with port 443 the most used:
Figure 3: Top ports used by VMware vCenter Servers
So far, we have been able to gather information about the product, version, and ports. But how do we know if a host is vulnerable or what percentage of those hosts are vulnerable? Shodan provides downloadable data that contains banners and other valuable information for each host. Figure 4 lists the command to download information.
Figure 4: Download results of query to a local file
Once data has been downloaded, we can use the parse option from shodan-cli to get information such as port number and version of the server (Figure 5). The build number is found in the HTTP response (Figure 6) as well as an object "vmware" in the JSON file (Figure 7). The os_type can be used to determine the Operating System (OS) of the server, for this example majority of the hosts, are using Linux (Figure 8).
Figure 5: Parsed port and version from the downloaded file
Figure 6: Sample HTTP response with server details from the downloaded file
Figure 7: Sample object “vmware” from the downloaded file
Figure 8: Count of OS types using the “vmware” object
Hosts vulnerable to vCenter Server vulnerabilities
The downloaded data from Shodan is a compressed JSON file that can be parsed using simple scripts to check if the host’s version is affected by these vulnerabilities (Figure 9).
Figure 9: Parsed version, build number, OS type, and classification
Out of 4969 data downloaded from Shodan, 4019 (80.88%) are vulnerable (Figure 10).
Figure 10: Count of total, vulnerable, and not vulnerable servers
Unfortunately, most of those “not vulnerable” 950 (19.12%) hosts are old versions (e.g., 2.5.0, 4.0.0, and other "end of life" (EOL)), and only eight hosts have versions that are supported. Implying that majority of these are not patched since they are unsupported (Figure 11).
Figure 11: Versions of servers that are not affected, but mostly EOL
Proof-of-Concept
As of writing this post, there are Proofs-of-Concept already for exploiting the RCE in the wild:
- https://www.iswin.org/2021/06/02/Vcenter-Server-CVE-2021-21985-RCE-PAYLOAD/
- http://noahblog.360.cn/vcenter-cve-2021-2021-21985
- https://attackerkb.com/topics/X85GKjaVER/cve-2021-21985
- https://github.com/alt3kx/CVE-2021-21985_PoC
Mitigation & Detection Guidance
The best way to protect your server is by applying the patch provided by VMware. This is the fastest and recommended way to remove the vulnerability completely. However, if you can't patch immediately, you should add the following lines under "pluginsCompatibility" element in your compatibility-matrix.xml file:
<PluginPackage id="com.vmware.vrops.install" status="incompatible"/>
<PluginPackage id="com.vmware.vsphere.client.h5vsan" status="incompatible"/>
<PluginPackage id="com.vmware.vrUi" status="incompatible"/>
<PluginPackage id="com.vmware.vum.client" status="incompatible"/>
<PluginPackage id="com.vmware.h4.vsphere.client" status="incompatible"/>
Then stop and restart the “vsphere-ui” service. This will disable the plugins affected by these vulnerabilities. Please consider checking the importance of these plugins from your system before disabling them. See more details and tips for patching from VMware’s blog post and article.
Trustwave Security Testing Services customers can detect vulnerable instances of VMware vCenter Server on their managed and self-service vulnerability scans.