May 26, 2021
On 25 May 2021, VMware released a new VMware Security Advisory, VMSA-2021-0010 marked with Critical severity. VMware continues in their practice of releasing one VMSA for multiple CVEs with different severities – we’ll break these down below. Are these CVEs interconnected? How do they impact your infrastructure? Is there a need to panic?
CVE-2021-21985 (note that at the time of publishing this article, the National Vulnerability Database, or NVD, has not yet updated the public page for this vulnerability) details a VMware vCenter vulnerability which has a Critical severity CVSSv3 score of 9.8.
The vSphere Client vSAN Health Check plug-in is missing input validation, allowing an attacker with network access to vCenter port 443 to exploit the issue and execute commands with unrestricted privileges directly on the vCenter server operating system. That's pretty nasty, right? A patch fixing the problem is available for vCenter 6.5, 6.7, and 7.0.
Note that while the plugin is present in vCenter 6.0, this release has reached the End of General Support, so there is no patch. An excellent reason to upgrade! A potential workaround is to disable the vSAN plug-in and mark it as incompatible, so that it doesn't attempt to load (note that simply disabling the plugin will not mitigate this vulnerability). We'll discuss that option later.
CVE-2021-21986 (note that the NVD has not yet updated the public page for this vulnerability) has a Moderate severity.
The vSphere Client plug-ins vSAN Health Check, Site Recovery, vSphere Lifecycle Manager, and VMware Cloud Director Availability contain vulnerabilities in the authentication mechanism. This vulnerability allows the attacker with network access to the vCenter to perform any operation permitted to the plugin without authentication. While not as bad as the previous vulnerability, this remains a concerning attack vector. Patches are available, and the same workaround as for CVE-2021-21985 applies.
A potential mitigation strategy and one that you should consider when designing the architecture of these environments is that the vCenter Server and other management functionality should be segregated from the wider network, with access only through a bastion host. Doing so would make it harder to exploit this vulnerability, but good patching hygiene is still essential.
A quick search on Shodan shows that a significant number of vCenter servers are directly accessible from the internet – if yours is in that list, you’re probably already too late… Patch that environment, secure it so that access is available only to those who need it and consider doing some form of forensics to check for compromise. Remember, these attacks allow access *without authentication*.
Of course, there would be no external technical or political reason to avoid patching your vCenter(s) as soon as possible in an ideal world. It's a good idea to be prepared for such a case and have all the potential showstoppers resolved in advance (have all the vCenter-dependent services up-to-date and have pre-approved emergency change).
The workaround detailed in KB 83829 (How to Disable VMware Plugins in vCenter Server) describes how to perform the workaround and disable the plugin effectively (as mentioned above, and highlighted in the KB you must set the plugins as “incompatible”. Simply disabling them does not mitigate the issue). The main question is not how to do it, but if that's a good idea to do it in your environment. Aren't you using any of the plug-ins listed above? Cool, then simply disable those and forget about the issue.
Do you have vSAN in your environment and can't patch your vCenter immediately? Then you'll have a decent headache out of that. You can disable the plug-in, vSAN will not stop working (at least not immediately), but you are losing all the vSAN monitoring and management. You can live with that for a few days, but not forever. Are you using the Site Recovery plug-in? That can be disabled, and you can still manage the tool directly from the SR appliance UI. It's maybe not that comfortable, but it works. The same applies to the vCloud Director plug-in. Disabling the Lifecycle Manager means that all the patching is manual.
In case you've disabled these plug-ins temporarily, don't forget to re-enable them (at least the used ones) after the vCenter is patched; it will not happen automatically.
Consider also those using HCI products like VxRail and VMware Cloud Foundation: if running VCF4, there is presently no patch available. Now would be an excellent time to reach out to your account manager, TAM or other contacts to ensure that you get the patch as soon as possible. Meantime, consider the mitigation strategies detailed above – if access is restricted to the vCenter Server to a sufficient degree, then running with the plugins enabled will likely be less concerning until such a patch is available. If you do not have such segregation, now may be a good time to reassess your architecture.
This VMSA reminder that a management network segregated from the wider network is a must and not just nice to have. It is also a reminder that some vCenter components are always enabled just in case somebody might need them, and it might not be a bad idea to review and possibly disable them in advance. Consider VMSA-2021-0002, which also had a vulnerability caused by a plugin in the vCenter Server that was present whether you needed it or not.
Runecast Analyzer knowledge definition version 220.127.116.11, released on Wednesday, 26th May 2021, just a day after the VMSA was published, includes detection and reporting for this VMware Security Advisory. As always, where automatic updates are enabled, Runecast Analyzer users will receive the new definitions during the following update cycle, with offline updates available through the Runecast customer portal as usual.
With our improved visibility focused on the CVE details, we have decided to split the announcements in the VMSA into separate findings. This approach allows greater visibility into the individual impacts, prioritizes remediation efforts on the highest severity issues, and helps with environment auditing. Also worth highlighting is the fact that you no longer need to go hunting for these vulnerabilities – we put them front and centre with the Vulnerabilities widget on the main Runecast Analyzer dashboard! Our vulnerability management capability includes all previously detailed VMware Security Advisories, as well as vulnerabilities in other technologies, such as Kubernetes.
We hope that these blog posts are helpful. Sometimes, the abundance of technical information in a Security Advisory means that it can be hard to fully understand the impact that the vulnerabilities and the fixes might have on your environment, and we’re always happy to help. As always, you can hit us up on Twitter with any feedback!
Our customers and partners tell us that, once they tried Runecast Analyzer, they couldn’t afford NOT to use it in their tech stack.