Just three steps to administrative credentials, say Guardicore researchers, using LDAP privilege escalation as a starting point.
On April 9, as many were getting ready in the UK for a long Easter Bank Holiday weekend, VMware quietly pushed out a security advisory for a major vulnerability in vCenter — the centralised management utility for the server and desktop virtualisation giant’s customers.
The fix was for a critical flaw that, if exploited, would give an attacker access to the crown jewels of corporate infrastructure: the bug sits at the heart of vmdir (VMware directory service), which is central to a product that manages thousands of virtual machines and virtualised hosts.
“A malicious actor with network access to an affected vmdir deployment may be able to extract highly sensitive information which could be used to compromise vCenter Server or other services which are dependent upon vmdir for authentication,” VMware said in a terse report.
(The vulnerability affects VCenter Server 6.7, if upgraded from a previous release line such as 6.0. Clean installations are not affected.)
Whoever disclosed the bug (CVE-2020-3952) did it privately; no credit was given. Its CVSS score however? A perfectly critical 10.
VMware Vulnerability CVE-2020-3952: LDAP Privilege Escalation, with Bells On…
Now security researchers at Israel’s Guardicore say they have been able to reach “disturbing” results that prove an unauthenticated attacker can create admin user status with three “simple” operations over the Lightweight Directory Access Protocol (LDAP) client-server protocol.
They say that the vulnerability is caused by two critical issues in vmdir’s legacy LDAP handling code — and worryingly, found that it appeared to have been noticed by at least one VMware developer as long ago as August 2017, as a Github commit revealed after some digging by the team.
1: “A bug in a function named VmDirLegacyAccessCheck which causes it to return “access granted” when permissions checks fail.
2: “A security design flaw which grants root privileges to an LDAP session with no token, under the assumption that it is an internal operation.”
“The server assumes that requests that are missing a token originate from inside the system, and should therefore be allowed to proceed.”
They explained to Computer Business Review: “Anytime you try and perform an action in LDAP (for example, adding a user), the server first marks whether this is an ‘anonymous’ user or not. Any user who provides credentials — even incorrect ones — is considered ‘non-anonymous.
“This isn’t a problem in and of itself, since the server checks later on whether the user’s authentication is valid. The problem is that this check has a bug. The server assumes that requests that are missing a token originate from inside the system, and should therefore be allowed to proceed.
“Unfortunately, when an external authentication attempt fails, the token is emptied out. This means that the vCenter Directory service thinks that this request originated internally any time a user fails to authenticate.
“There’s one last check that should, theoretically, hold an attacker at bay (and this is the single check that VMware fixed of these three issues). This check is supposed to determine whether the request has the specific privileges needed for the particular action taking place. When the vCenter Directory service is running in ‘legacy mode’, this check has a very serious bug: it always allows the requested access. This is probably the most flagrant bug.”
The Guardicore team have now put together an exploitation script that runs all stages of the exploit, so researchers can try it themselves. (Happy days for black hats as well as red hats, if anyone still needed an incentive to patch urgently). There are over 2.8k vSphere LDAP services exposed to the Internet. Out of them over 1k are running version 6.7, they told us.
The two added that “Perhaps the most distressing thing, though, is the fact that the bugfix to VmDirLegacyAccessCheck was written nearly three years ago, and is only being released now. 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.”
How did this happen?
“Breaking code changes often do take a long time to reach deployment, and VMware is about is big as they come. This is particularly difficult in a product like vSphere, where patches can mean extended downtime for users. That said, three years is a very long time for this kind of oversight to take place.
They added: “Based on the commit messages and comments in vmdir’s code, we believe that the developers at VMware didn’t understand the full implications of this bug. They were aware that there is a privilege escalation possible when “legacy mode” is enabled in vCenter Directory, but it doesn’t seem like they were aware until recently that this privilege escalation can be reached from outside the vCenter. In other words, they thought that this bug will only take place for LDAP requests originating from the system itself, but not from a remote user.
Recommended (other than the basics of patching and/or upgrading) steps include limiting access to vCenter’s LDAP interface.
“In practice, this means blocking any access over the LDAP port (389) except for administrative use.”
Guardicore’s full technical write-up is here.