VMware recently patched a critical authentication bypass vulnerability in their VMware Workspace ONE Access, Identity Manager and vRealize Automation products (CVE-2022-22972). This vulnerability allows an attacker to login as any known local user.
The VMSA from VMware doesn’t give many details about the inner workings of this vulnerability. However, they do provide patch and workaround instructions. Digging into the patch is a good starting point. For our purposes, we are using vRealize Automation 7.6 which contains an embedded vIDM. Note that other products and versions have different auth workflows and endpoints. The patch downloads and details can be found here https://kb.vmware.com/s/article/70911. As of this writing, the most recent patch which addresses CVE-2022-22972 is 28.
VMware releases cumulative patches, which means that patch 28 addresses all vulnerabilities since the inception of the product. This makes it rather difficult to find out exactly how the most recent vulnerability is addressed. To remedy this issue, we downloaded patch 27 to compare with patch 28. After extracting the patches, we find that there zip files named
patch-vRA-7.6.0-19482496-HF27.content in patch 27 and in
patch-vRA-7.6.0-19772459.19640138-HF28.content in patch 28. We extract these zip files to find more of the content of the patches. There aren’t many notable differences in the patch content folders, but we see that the horizon service rpm has moved.
rpm2cpio to extract the contents of the two rpms. We find three differences,
frontend-01.war. We extract the
.war files to find the following in
Notably, we find a new
HostHeaderFilter.class file and some differences in
web.xml which shows the new
HostHeaderFilter is applied to all url patterns.
We can use a Java decompiler to convert
We see that this filter is denying any request with a
Host header that is deemed invalid. Based off of this, we can start sending requests to the application with strange host headers.
After unsuccessfully poking around various endpoints, we noticed something strange when sending an invalid host header to the login endpoint. We set the
Host header to a bogus value of
There is nothing notable about the request itself, but if we look at
horizon.log on the appliance, we can see that the application is trying to resolve
This indicates that the application is trying to make a connection to whatever we put in the
Running a Login Server
Let’s try to get the app to connect to us to see what kind of information it is trying to send. We wrote the following simple https server:
After inserting our IP address into the host header, we see a new exception in the log:
This failure indicates that the application is not able to validate our certificate. This makes sense because the certificate on our server is self-signed. After we add our certificate to the Java certificate store on the appliance, we can see that the application does indeed connect to us and sends us the login information in an HTTP POST request. Note that an attacker would not have to replicate this step. They could instead host their login server on a public server with a valid certificate.
The application expects a response from the HTTP server to know if the user should be granted access. To account for this, we rewrite our server to respond with a status 200 to any POST request.
With new server, we are able to successfully log in!
Automating the Exploit
So far we have been using Burp Suite proxy to modify requests sent by a browser, but now we would like to automate this workflow for use in exploit scripts. We ultimately would like to sent a POST to the
SAAS/auth/login/embeddedauthbroker/callback with a custom
Host header. This endpoint requires some additional metadata to be encoded in the body of the POST. If we examine the source of the login page we find the information we need in hidden form fields.
Our POC sends requests starting at the
/vcac endpoint the same way a browser would and parses the login page to extract these hidden fields. These hidden fields are then encoded into the body of the final POST with the
Host header set to our custom login server. The POC then parses the response to extract the authentication cookies. These cookies can be used to execute actions as the chosen user.
This script can be used by bypass authentication on vRealize Automation 7.6 using CVE-2022-22972. Workspace ONE and vIDM have different authentication endpoints, but the crux of the vulnerability remains the same.
Our POC can be found here https://github.com/horizon3ai/CVE-2022-22972
CVE-2022-22972 is a relatively simple
Host header manipulation vulnerability. Motivated attackers would not have a hard time developing an exploit for this vulnerability. A quick search on Shodan.io for the effected VMware applications returns a pretty low count of organizations that expose them to the internet. Of note, the healthcare, education industry, and state government all seem to be a fair amount of the types of organizations that have exposures – putting them at larger risk for current and future exploitation. Organizations should address these issues by immediately following the guidance within the VMware Security Advisory.