Very High
CVE-2020-3952 - VMware vCenter Server vmdir Information Disclosure
CVE-2020-3952 - VMware vCenter Server vmdir Information Disclosure
Description
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.
Add Assessment
Technical Analysis
Technical details on the vuln are out: https://www.guardicore.com/2020/04/pwning-vmware-vcenter-cve-2020-3952/. It’s quite a bit more than information disclosure. Full auth bypass and the ability to add an arbitrary admin user. I’ve confirmed it myself and added a second module.
ETA: I noted the following in an earlier response here:
The data seemed to contain secrets related to VMware’s Security Token Service (STS) for single sign-on (SSO).
So information disclosure is still on the table for obtaining access. Presumably, you would use the STS private key to sign forged SAML tokens used in the STS SSO system. Wanted to update AKB, since we’d been talking about it in work Slack. :)
Hats off to the Guardicore team for their dedicated analysis.
Technical Analysis
The vmdir VCenter process appears to expose internal data via an unauthenticated, unencrypted LDAP service. See Metasploit module PR for exploitation details: https://github.com/rapid7/metasploit-framework/pull/13253 . Given that this vuln appears to not exist in a ‘fresh’ install, this looks like a legacy configuration option that should have been disabled much earlier. Possible that importing an old configuration might reenable this.
Since my original assessment, we found that this vulnerability also allows anyone with unauthenticated network access to create arbitrary users in vCenter, allowing for full unauthorized access to the vCenter environment and the virtual machines within.
Blocking LDAP port 389 may be an intermediate mitigation.
Thanks for the writeup! The data seemed to contain secrets related to VMware’s Security Token Service (STS) for single sign-on (SSO).
This frightens me!
Replying to expand guidance to ensure ports 636, 389, and 3268 should not be exposed to the internet unless one really knows what they’re doing. We’ve found vCenter nodes on all three of those common LDAP ports, even in the April studies.
Technical Analysis
CVSS 10 according to vendor
Technical details shared by Guardicore : from unauthenticated to admin (via LDAP). Implemented in a public exploit
MSF module to come.
Your Twitter thread on this was really helpful as @wvu-r7 was working through module code, thanks!
I actually didn’t know about the Twitter thread until @cnotin commented in the PR. :(
That’s collaboration @wvu-r7 🙌
Thanks for the help!
Technical Analysis
Previous tech analyses cover this quite well, but my mind is literally broken trying to figure out how:
- 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.
made it past any semblance of code review.
Regardless of ^^, this is a bit worse since attackers can also be a bit less noisy.
Our LDAP Sonar studies do no attempt at auth and we get SearchResultEntry$PartialAttributes$vmwPlatformServicesControllerVersion from the search results query we perform, so it’ll be super easy for anyone to only target 6.7.0 systems. There are under 1,000 6.7.0 systems hanging off the internet on 389.
recog also pulls the version out directly if anyone is using that to post-process LDAP responses.
Thanks for the exposure info. It really isn’t subtle about announcing its presence is it?
CVSS V3 Severity and Metrics
General Information
Vendors
- vmware
Products
- vcenter server 6.7
Metasploit Modules
