Close on the heels of last two incomplete patch releases from VMware to address high severity privilege escalation and denial-of-service (DoS) flaws in the Workstation, Fusion, Remote Console and Horizon Client in March, VMware tried to address another critical vulnerability this month.

Last two patches were for a privilege escalation vulnerability affecting the macOS version of Fusion. However, the researchers who reported the flaw to VMware said both of them were incomplete. The two security vulnerabilities have been tracked as CVE-2020-3950 and CVE-2020-3951 respectively. However, earlier this month, VMware addressed a critical information disclosure flaw, tracked as CVE-2020-3952, that could be exploited by attackers to compromise vCenter Server or other services that use the Directory Service (vmdir) for authentication.

“A sensitive information disclosure vulnerability in the VMware Directory Service (vmdir) was privately reported to VMware. vCenter updates are available to address this vulnerability.” reads the advisory published by VMware. “Under certain conditions, vmdir that ships with VMware vCenter Server, as part of an embedded or external Platform Services Controller (PSC), does not correctly implement access controls. VMware has evaluated the severity of this issue to be in the Critical severity range with a maximum CVSSv3 base score of 10.0.”

It resides in the vCenter Server version 6.7 on Windows and virtual appliances. According to VMware, the vulnerability could only impacts vCenter Server 6.7 installations, if they were upgraded from a previous version, but not if the user directly installed version 6.7. The vulnerability has been addressed with the release of the 6.7u3f update.

Cloud and data centre security solutions provider Guardicore made available technical information on this critical VMware vCenter Server vulnerability. Experts at Guardicore analysed the patch issued by VMware and released the technical analysis of the vulnerability. An attacker with network access to a vCenter Server LDAP service can exploit the issue to create a user with full privileges on the vCenter Directory gaining full control over the VMware deployment. In short, it would be a remote takeover of the entire vSphere deployment.

According to Guardicore, “Despite the relative clarity of VMware’s code, it looks like there were quite a few missteps that went into the vulnerability. The developers were at least partially aware of them, too, as we saw in the code comments and commit messages.” It is also noteworthy that the bugfix to VmDirLegacyAccessCheck was written nearly three years ago, and the company only now released it. Considering that three years is a long time for something as critical as an LDAP privilege escalation not to make it into the release schedule — especially when it turns out to be much more than a privilege escalation, the experts are speculating that VMware was aware of the issue, but for some reason, it failed to address it.

Guardicore implemented a proof of concept for this exploit and provided more details in a post, which explains, “The vulnerability is enabled by two critical issues in vmdir’s legacy LDAP handling code:

  • A bug in a function named VmDirLegacyAccessCheck which causes it to return “access granted” when permissions checks fail.
  • A security design flaw which grants root privileges to an LDAP session with no token, under the assumption that it is an internal operation.”

In a blog post, Ofri Ziv, Head of Research at Guardicore and Guardicore Researcher JJ Lehman explained at length how its researchers were able to pwn vCenter after inspecting the source on GitHub. Lehman and Ziv could create a new user account and assign them full admin permissions, all because vCenter did not thoroughly authenticate and cross-check external inputs.

According to Lehman, “You have to be network-accessible but you don’t have to be authenticated in any way to pull this off. Which means as an attacker who has already breached the perimeter of a network, as long as [you have] access to the vCenter, you essentially control everything on their VMware hosts.” Ofri categorised it as a critical issue and believes that it’s important for people to understand and mitigate it as fast as possible. However, he added that Guardicore has not seen evidence of the vulnerability being abused in the wild, though Lehman explained that by its nature, it would be difficult to see traces of its use.

References: