Overview
A common attack path that Horizon3 has identified across many of its customers is abusing access to the VMware vCenter Identity Provider (IdP) certificate.
Security Assertion Markup Language (SAML) has proved to be a hotbed of vulnerabilities within the last year, as well as a target of many cybercrime syndicates and APTs. In the SolarWinds attack, the attackers also abused access to VMware One SAML certificates to gain access to cloud assets and remain undetected.
Services that support single sign-on (SSO) typically use an authorization solution like SAML. When a user logs into a remote service, that service forwards the authentication request to the SAML Identity Provider. The SAML Identity Provider will then validate that the user credentials are correct and that they are authorized to access the specified service. An example of a SAML Identity Provider is Active Directory (AD) for Windows domains, or Azure AD for hybrid or cloud environments.
Attackers seek to compromise the servers where the Identity Provider certificate is stored because the certificate will enable them to forge valid login credentials for any incorporated service as any user. What makes this type of attack even worse is that with this forged credential, it typically allows attackers to bypass multi-factor authentication. This essentially gives attackers the keys to the kingdom.
vCenter Single Sign-On and Directory Services
VMware vCenter provides its own SSO service so that users can use one set of credentials for all VMware services. The VMware Directory (vmdir) service is largely responsible for vCenter SSO services and stores critical authentication information like local vCenter usernames and passwords hashes as well as the SAML certificates. The vmdir service is accessible over port 389/tcp with authentication as well as available locally on the VCSA host with root permissions. Depending on the operating system for the VCSA host, the information is store at different locations:
- Linux:
/storage/db/vmware-vmdir/data.mdb - Windows
C:\ProgramData\VMware\vCenterServer\data\vmdird\data.mdb
Dangerous Defaults and Recent Vulnerabilities
Over the past year at Horizon3, our APTaaS tool “NodeZero” has discovered several extremely common paths to obtaining the VMware Directory service data.mdb file in our customer environments.
Path 1: vCenter Backups
One of the most common issues NodeZero has discovered in customer environments is unsecured or poorly secured network file shares. It is incredibly common to find backups for critical infrastructure – including vCenter. The vCenter backups contain all the critical information to restore a vCenter instance. Inside the backup is an archive called lotus_backup.tar.gz. Inside the archive, you will find the data.mdb file.
Path 2: Recent Vulnerabilities
Over the past year, three major vulnerabilities have been discovered allowing access to this critical information:
- CVE-2020-3952: Allows an unauthenticated, remote attacker to obtain any information from the VMware Directory services over port 389/tcp. This vulnerability allows the attacker to obtain the IdP certificates to forge a login request.
- CVE-2021-21972 and CVE-2021-21985 : Allows an unauthenticated, remote attacker to execute arbitrary commands against the VCSA host with vsphere-ui user permissions. Chaining this with other recent Linux local privilege escalations such as the Sudo bug (CVE-2021-3156) which allows an attacker to obtain the data.mdb file. The NCC Group recently published a great article abusing CVE-2021-3156 against vCenter specifically.
- CVE-2021-22005: Reported just last week, this allows an unauthenticated, remote attacker to execute arbitrary commands against the VCSA host with root permissions.
Extracting the IdP Certificates and Compromising vCenter
With root or administrative permissions, it is possible to extract the IdP certificates from the directory service information located within the data.mdb file. These certificates are stored in cleartext and can be used to sign any SAML authentication request for any user – including the builtin Administrator. We’ve written a tool that automates the extraction, creates a SAML request for the Administrator user, signs the request with the extracted certificates, and authenticates with the vCenter server to obtain a valid Administrator cookie.
Now, visit the VCSA instance at https://<VCSA>/ui, add the cookie under the /ui path, and re-browse to https://<VCSA>/ui.
You will now be logged in as the Administrator user and able to access all vCenter resources.
How To Prevent
The most common paths to obtaining the VMware Directory service data is through misconfigurations and vulnerabilities. By staying on top of vCenter patches and auditing the access controls of any network files shares that store backups you can mitigate this attack vector.
One additional recommendation for added security is to configure encryption for vCenter backups. You can easily configure encryption by following this vCenter Backup Guide. By encrypting the backups, extraction of the data.mdb file becomes impossible.
vCenter Post-Exploitation
Check back for future posts in this series where we will cover extended post-exploitation techniques that cover pilfering other credentials within vCenter, gathering information to be used in other attacks, and virtualized host post-exploitation.
Proof of Concept
The tool we created can be found on our GitHub repo: https://github.com/horizon3ai/vcenter_cert_login
