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/Version
Update To
Notes
vCenter 7.0
7.0 U2d
The majority of issues are fixed by going to U2c. U2d resolves CVE-2021-22011 and CVE-2021-22018
vCenter 6.7
6.7 U3o
This version will resolve all the associated issues with 6.7
vCenter 6.5
6.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.
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.
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.
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:
Backup the VCSA (via snapshot or other means)
Reboot the VCSA
During the boot process, when the photon splash screen appears press the e key to get into the boot menu
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
Press F10 to continue booting
At the command prompt, run the passwd command to reset the password
Unmount the file system by running umount /
Reboot the VCSA using reboot -f
Following reboot, confirm the new password works
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
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’
The log had numerous entries for 192.168.1.55 trying to login using root and other accounts. The system on 192.168.1.55 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.
