Team!
Hey everyone! It’s Monday, but for some reason I already thought it was Tuesday. Must be one of those weeks already! ? A lot of talk regarding security recently. Whether it’s additional findings and what’s to come of the SolarWinds breach, another side-channel attack in Intel processors, or these critical and important vulnerabilities found in VMware’s codebase, which is what we are going to talk about tonight.
The Deets
First, we’ll start with Code-execution flaw found in VMware vCenter (CVE-2021-21972). This monster has a whopping 9.8 out of 10 severity, so if you haven’t patch, do it. If you can’t patch, there’s a workaround. And if you’re unsure, reach out to me directly and I’ll do what I can to guide you or assist you in a remediation effort. This vulnerability allows attackers unrestricted remote code-execution capabilities at the OS-level. Oh, and to add to this, they don’t even need prior authentication or authorization to do so, which is why this is so dangerous. I won’t go into all the exploit-related details (find those here) but the issue lies within the vROPs plugin for vCenter. Please note that this plugin is present even if you don’t have a vROPs infrastructure.
Who’s Affected?
If you’re vCenter version is 6.5 prior to 6.5U3n, 6.7 prior to 6.7U3l, or 7.0 prior to 7.0U1c running on any platform you are affected. VCF is also affected by this so if your infrastructure is running version 3.x then you need to patch up to 3.10.1.2, or 4.2 if you’re already on 4.x.
Help Me, Tom Cruise!
The easiest way to put this mess behind you is to simply patch up to the minimum version I just mentioned. In some cases, patching may not be possible for whatever the reason. Well, VMware has released workarounds for the non-patchers, which I’ve linked to here. To sum up the workaround, you’re editing (after you back up the original, of course!) the compatibility-matrix.xml file and adding a line to flag the vROPs Client Plugin as ‘Incompatible’. Disabling the plugin is NOT ENOUGH! Didn’t mean to yell there, but I wanted to hammer that home. Patching or following the workaround to the T are the only ways to protect yourself in this case.
But Wait, There’s More!
As if that wasn’t bad enough, VMware has another 8.8-rated vulnerability lurking in the shadows of ESXi. CVE-2021-21974 describes a remote code execution exploit in the OpenSLP daemon in ESXi. Again, the affected versions are ESXi 6.5, 6.7, and 7.0, as well as VCF 3.x and 4.x. If you can patch, you’ll need to jump up to ESXi650-202102101-SG, ESXi670-202102401-SG, or ESXi70U1c-17325551, respectively for traditional ESXi, or 6.7 EP 18 (click here for the KB on patching VCF 3.x) or 4.2 for VCF. Workarounds are also available in this scenario too and can be located here.
What More Can I Do to Protect Myself?
Look, nothing is 100%, and when it comes to information security it’s all about a layered approach. Aside from the patches mentioned, there’s more that you can do to help protect your VMware infrastructure. In fact, they are practices that really should apply across the entire IT organization, but the article’s sake let’s apply them to vSphere.
- Least-Privileged Access or Zero Trust model – Only give users enough access to your VMware environment that is needed to complete a task or their job.
- Disable unnecessary services until they are needed – I’ve run into a lot of VMware Admins that like to keep things like SSH enabled all the time, but me personally, I like the service disabled unless I need to use it. One less vector available to potential attackers. ESX Shell and DCUI are additional prospects to consider.
- Root and SSO Admin Access – rotate these passwords. If you have a password manager randomize and store them securely. Please don’t use the same passwords across all your hosts. Sure, it’s easy to remember in case of an emergency, but it’s just as easy to breach all your hosts and own every VM when this practice is in place. Most passwords managers have a function to auto-rotate the passwords for you. There are free enterprise-grade password managers out there if you don’t have a budget for one.
- Follow the vSphere Security Configuration Guide for your version. Here’s a link to the landing page. From there just select your version and download the guide. These provide baselines for security and auditing for vSphere.
Conclusion
That wraps up this post regarding the recent vulnerabilities found in vCenter and ESXi. Tonight, we discussed them, how to mitigate and remediate, and provided a few extras on securing your VMware infrastructure. Thanks for reading. If you enjoyed the post make sure you check us out at dirmann.tech and follow us on LinkedIn, Twitter, Instagram, and Facebook!
References:
https://swarm.ptsecurity.com/author/mikhail-klyuchnikov/
Paul Dirmann (vExpert PRO*, vExpert***, VCIX-DCV, VCAP-DCV Design, VCAP-DCV Deploy, VCP-DCV, VCA-DBT, C|EH, MCSA, MCTS, MCP, CIOS, Network+, A+) is the owner and current Lead Consultant at Dirmann Technology Consultants. A technology evangelist, Dirmann has held both leadership positions, as well as technical ones architecting and engineering solutions for multiple multi-million dollar enterprises. While knowledgeable in the majority of the facets involved in the information technology realm, Dirmann honed his expertise in VMware’s line of solutions with a primary focus in hyper-converged infrastructure (HCI) and software-defined data centers (SDDC), server infrastructure, and automation. Read more about Paul Dirmann here, or visit his LinkedIn profile.
