VMSA-2021-0020 – 19 vulnerabilities on vCenter

VMware published a new security advisory overnight (VMSA-2021-0020) and it’s a big one. In total, it lists 19 vulnerabilities affecting multiple versions of vCenter. The most serious of the vulnerabilities is the first one – CVE-2021-22005. This vulnerability allows an attacker to upload files to vCenter. This vulnerability could then be used as an avenue to execute code. It’s been giving a CVSS score of 9.8

The second most worrying item on the list (CVE-2021-21991) allows an attacker to escalate their priveleges to Administrator level in the vSphere web interface. This vulnerability has been scored at 8.8.

The resolution for all these vulnerabilities is to update vCenter to the appropriate version. The advistory lists these, and I’ve produced a condensed version below.

Product/VersionUpdate ToNotes
vCenter 7.07.0 U2dThe majority of issues are fixed by going to U2c. U2d resolves CVE-2021-22011 and CVE-2021-22018
vCenter 6.76.7 U3oThis version will resolve all the associated issues with 6.7
vCenter 6.56.5 U3q This version will resolve all the associated issues with 6.5

Given the nature of some of these vulnerabilities, this would be one to get onto ASAP.

Remediating VMSA-2021-0002 – Potential Issues

In late February, VMware published their second security advisory for 2021. It contained contained three items:

  • CVE-2021-21972 – A remote code execution vulnerability in vCenter that has a CVSS score of 9.8
  • CVE-2021-21974 – A vulnerablity in OpenSLP, which is used in ESXi. This one has a CVSS score of 8.8
  • CVE-2021-21973 – Another vCenter vulnerability that was rated with a CVSS score of 5.3

Given the product versions affected, most organisations with relatively up to date virtualisation infrastructure would be at risk from these items. While testing and simulating the update process, I ran into some issues that might be worth publishing for a broader audience.

Read more

Installing ElasticStack Beats on vCenter 6.7

I recently deployed a vCenter appliance to 6.7 after a power outage corrupted the 6.5 instance.  A followup task for the virtual appliance was getting the ElasticStack Beats (MetricBeat, Filebeat) installed again.  In this post, I will go through the process of installing the Beats and some of the minor issues I ran into.

Read more

VCSA 6.5 Root Account Password – Reset and Cause Investigation

One of the more frustrating experiences one can experience with VMware’s vCenter Server Appliance (VCSA) is having the root account locked out or forgetting the password for it.  I recently experienced this after I rebuilt the VCSA in my home lab from scratch.

How to Reset the VCSA Root Password

VMware have a short process on how to reset the password for the root account, detailed in KB2147144.  THe process is:

  1. Backup the VCSA (via snapshot or other means)
  2. Reboot the VCSA
  3. During the boot process, when the photon splash screen appears press the e key to get into the boot menu
  4. In the text box that appears, go to the line starting with “linux”.  Go to the end of the line (which is right after the text “consoleblank=0”) and enter the text rw init=/bin/bash  This will cause the boot process to jump right into the bash shell without needing credentials
  5. Press F10 to continue booting
  6. At the command prompt, run the passwd command to reset the password
  7. Unmount the file system by running umount /
  8. Reboot the VCSA using reboot -f
  9. Following reboot, confirm the new password works
  10. If you took a snapshot in step 1 remove it


Cause Investigation

After resetting the password and restarting, I still couldn’t login.  One thing I noticed was there had already been 20 login failures.  In my situation, the VCSA was working one evening and the following morning the login issues happened.  Something had to be causing these issues.  Using the password reset process to get to the bash shell again, I looked around in some logs.  First I tried checking the /var/log/messages log.

Failed Logins search using grep
Failed Logins search using grep

Unfortunately, using ‘FAILED’ only showed 2 login attempts on the console which were caused by myself after the lockout happened.  Failed SSH login attempts are logged under a text string that uses ‘Failed”.  The second search attempt used ‘Failed’ and yielded better results.

Search results using 'Failed'
Search results using ‘Failed’

The log had numerous entries for trying to login using root and other accounts.  The system on was the trial of Nexpose.  Even though I didn’t have credentials set in Nexpose to logon to the VCSA, it still was trying to logon using root and was causing the failures.  This hadn’t been an issue prior to the VCSA rebuild.

I excluded the VCSA from the scanning that Nexpose performs and did the password reset process again.  I was now able to login successfully.