Very High
CVE-2020-3952 - VMware vCenter Server vmdir Information Disclosure
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
CVE-2020-3952 - VMware vCenter Server vmdir Information Disclosure
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportRatings
-
Attacker ValueVery High
-
ExploitabilityVery High
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportThanks 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.
Ratings
-
Attacker ValueVery High
-
ExploitabilityVery High
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportYour 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!
Ratings
-
Attacker ValueVery High
-
ExploitabilityVery High
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.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportThanks 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
Exploited in the Wild
Would you like to delete this Exploited in the Wild Report?
Yes, delete this reportReferences
Additional Info
Technical Analysis
Report as Emergent Threat Response
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below: