What’s the issue?
Three vulnerabilities were recently released by VMware’s security advisory and impact vCenter Server or ESXi — CVE-2021-21972, CVE-2021-21973, CVE-2021-21974.
Impacted Versions of vCenter:
- 7.0 prior to 7.0 U1c
- 6.7 prior to 6.7 U3l
- 6.5 prior to 6.5 U3n
Impacted Versions of ESXi:
- 7.0 before ESXi70U1c-17325551
- 6.7 before ESXi670-202102401-SG
- 6.5 before ESXi650-202102101-SG
However, CVE-2021-21972 is a critical remote code execution vulnerability according to Tenable. Using the data that powers our ASM Platform, the Censys team found 6,868 hosts across the Internet running this potentially vulnerable version of vCenter by VMware. Top countries where hosts were seen include the United States, China, Germany, France, and the United Kingdom.
|
Per Country |
% of Total |
| United States |
1641 |
24% |
| China |
592 |
9% |
| Germany |
447 |
7% |
| France |
390 |
6% |
| United Kingdom |
242 |
4% |
We deepened our search to determine only 38% are actually running on public cloud, mostly running on Amazon AWS. A further breakdown can be found below.
Why does this matter?
The recent vulnerabilities disclosed by VMware regarding their vCenter software is exceptionally bad news for administrators responsible for maintaining a secure virtual infrastructure. These vulnerabilities affect key pieces of critical infrastructure allowing an unauthenticated attacker to upload arbitrary files to critical infrastructure servers and also execute arbitrary code on those servers with SYSTEM user privileges (on Windows Servers). Administrators running vSphere on Linux may be in slightly less panic since access is more contained, but system level access is still achievable.
If you’re not already in a mad dash for your laptop to 1) ensure you’re not exposing vCenter to the entire Internet and 2) smash that ‘update now’ button – you should probably consider it if you’re running one of the almost 7,000 potentially vulnerable servers on the Internet. Code does exist in the wild to exploit these vulnerabilities, so it is important to move quickly to mitigate the risk from these vulnerabilities.
You can use the example query below to check your own infrastructure, just replace 8.8.8.8 with your IP address or CIDR range: https://censys.io/ipv4/help?q=%22ID_VC_Welcome%22+AND+ip%3A+8.8.8.8
These vulnerabilities combined are a special sort of “oh shit” moment for administrators. Anyone on the Internet being able to use your vCenter server as a cat meme CDN service is bad, but consider a few of the other things that an attacker might be able to access. For example, any systems running on the vSphere server could be compromised and should be inspected for changes or other IoCs. Also, because vSphere servers often aggregate different network segments – an attacker could pivot from the vSphere network to the internals of an organization’s office or data center potentially accessing services that are too sensitive to be connected directly to the Internet. Administrators will want to watch other systems that are connected or potentially connected to networks shared with the vSphere server.
Censys has also submitted a pull request to recog for better identification of vCenter in the future. With this change, customers who utilize recog directly, or who utilize products who utilize recog, will benefit from the new ability to more easily identify and secure these services.
What do I do about it?
Your first step should be to identify potentially impacted assets with the vulnerability. We have used the following queries to support the community in identifying impacted assets to investigate and remediate.
https://censys.io/ipv4/help?q=%22ID_VC_Welcome%22+AND+ip%3A+8.8.8.8
https://censys.io/ipv4?q=%22VMware+vSphere+is+virtual+infrastructure%22+AND+ip%3A+8.8.8.8
Once you find these impacted assets, you will need to either apply the work-around or update your vSphere appliances. Neither are much fun and can be difficult to do without losing functionality or creating downtime, but in this instance we doubt anyone will fight you.
Next, because this is a critical all-owning RCE – you’ll need to check each vSphere server for unexpected files, new services, ports open that you weren’t expecting, new accounts, or other things that are unusual for your environment. It’s really common for an attacker to establish persistence when compromising a service or server like this, so you’ll need to be meticulous and likely expand your search beyond the vSphere server itself.
Work-around instructions can be found here: https://kb.vmware.com/s/article/82374
Resources
