Introduction

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.

Patch Examination

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.

We use rpm2cpio to extract the contents of the two rpms. We find three differences, dbConnection-0.1-jar-with-dependencies.jar, analytics-0.1.war, and frontend-01.war. We extract the .war files to find the following in frontend-01.war:

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 HostHeaderFilter.class into HostHeaderFilter.java:

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.

Runtime Examination

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 asdf.

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 asdf.

This indicates that the application is trying to make a connection to whatever we put in the Host header.

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

Summary

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.