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

Adding extra service mappings to Nexpose

Nexpose does have good coverage of services in the “well known” range of ports (0-1024).  An environment with a lot of propriety systems will cause Nexpose to some services as unknown or even misidentifying them.  The screenshot below is a good example of this.

Nexpose Services Data
Nexpose Services Data

The example is from a Domain Controller.  Nexpose identifies the port 3389 service correctly as RDP.  Ports 3269/32769 are used by the Global Catalog service, so labelling them as LDAP/LDAPS isn’t strictly accurate.  For port 3260 and 5666 it gives up.  Depending on your needs, you may want to get these labels a bit more accurate.  This can be achieved by using a custom service names file (you can alter the default one, but it’s probably best to leave that in its default state).

The default file, default-services.properties, is located in the <install location>/plugins/java/1/NetworkScanners/1 folder.  The format is basic, with each line as <port #>/<tcp or udp>=<Service Name>.  Some of the custom ports I added are shown below:

Custom Service Mappings
Custom Service Mappings

 

Once the properties file is in a state you’re happy with, place it in the same folder as the default one and either create a new or edit an existing scan template and put the file name into the field on the Service Discovery section.  Load up the page of an asset to test and queue a scan on it with the scan template.  The reported services should update with the new values.

Close Bitnami banner
Bitnami