VMSA-2020-0006 / CVE-2020-3952 Demo PoC

The 14th of April I wrote about the recently released VMware Security Advisory (VMSA) VMSA-2020-0006 also known under its CVE name by CVE-2020-3952. At the time of writing that blogpost there weren’t any Proof of Concepts (PoC’s) available to show us what kind of information could be obtained through abusing the vulnerability. The 15th of April guardicore.com released a PoC to show what this vulnerability can do. After carefully reading the post I thought it would be fun to try and use the vulnerability myself, ofcourse only in our vCloudvision.com test environment and in the name of science! This was all done to show you everybody why you absolutely need to patch your environment as quick as possible!

A word of caution: As always, please don’t try this on any production environment. This blogpost and video was done to demonstrate why you need to update your environment as soon as possible from a security standpoint!

The vulnerability

I talked about the vulnerability extensively on the 14th of April, but to remind everybody, please read the below to understand it.

According to VMware under certain conditions a malicous attacker that has network access to an affected vCenter Server may be able to extract sensitive information from the vmdir process. The vmdird service is the VMware Directory Service that stores authentication, license, certificates and lookup information. The reason that this is possible is because the either embedded or external Platform Services Controller (PSC) does not correctly implement access controls which allows the attacker to bypass this mechanism. If an attacker would gain access to the vmdird service it might extract information that could be used to compromise the vCenter Server or other services that are dependent on the vmdird service.

These certain conditions under which a malicous attacker could gain access are mentioned in the VMSA-2020-0006 and are the following:

• LDAP port 389 to the vCenter Server has to be available to the attacker.
• Your vCenter Server 6.7, Windows or the Appliance, with or without an embedded Platform Services Controler (PSC) has to have been upgraded from vCenter Server 6.0 or 6.7 in the past.
  • If this is true you can find the following term in the vmdird-syslog.log file “ACL MODE: Legacy“.
  • Unfortunately this log entry will also keep appearing in your log file once you’ve updated to 6.7 U3f or 7.0. So check your versions!

According to guardicore.com there are several flaws in a couple of functions for the vmdird service which allow an attacker to essentially bypass a couple of security checks.

Proof of Concept Demo time

Like I said earlier we wanted to see if the vulnerability that VMware released, and fixed, was really worth the CVSSv3 score of 10 out of 10. So we decided to test out the publicly available information against our own vCenter Server #homelab. In the below video I explained the process.

After trying out the vulnerability on our environment, my only conclusion is that it’s definitely worth the CVSSv3 score of 10 out of 10. So again, patch your environment as soon as possible. If you want to know even more on a deeper technical level please head over to the guardicore.com website to find out!

Fixing the vulnerability

Currently the only way to fix this security vulnerability is to update your vCenter Server to version 6.7 U3f. There is no workaround available at this time. If you want to update your vCenter Server Appliance, this is very easy. Just follow the below couple of steps:

1. Login to the vCenter Server Appliance VAMI on https://vcenter.fqdn:5480
2. Browse to the Update section.
3. Check the available updates. If 6.7 U3f (6.7.0.43000) is available.
4. Select the update and click on “Stage and Install”.
5. The update will be installed and you have patched the environment.

Please don’t forget that the external PSC and the vCenter Server should be kept at the same versions to ensure compatiblity and stability and supportability! So you should update both! If you cannot patch your environment at this time, the only thing you can do to minimize risk and exposure is to lockdown the vCenter Server Appliance with firewall rules, especially the LDAP (389) port and seperate the vCenter Server Appliance from the data plain (this is always recommended!!). This will however not “fix” the issue! You are still vulnerable!

Please also read the FAQ VMware made that belongs with the VMSA just in case I missed something noteworthy.

Please also sign-up to the VMware Security Advisories HERE to be notified about future VMSA updates.

## We did not create the script or performed the research that allowed us to test this vulnerability. Credits for this go to Guardicore.com.
## We are not responsible for any damage to your vCenter Server environment if you decide to test this vulnerability or if others try this against your vCenter server.