As enterprises take on the challenge of managing identity at scale, often, enterprise products such as VMWare Workspace One Access are used to facilitate this. In this blog post, we take a look at a critical piece of software used by enterprises to manage multi-factor authentication and SSO.
While the vulnerability found was post-authentication, an attack vector exists to leak an administrative JWT using the SSRF through CSRF. This increases the severity of the issue as this vulnerability can be used in spear phishing attacks against organizations that use VMWare Workspace One Access.
Additionally, in this blog post, we focus on the basic elements of source code analysis that led to the discovery of this vulnerability, in hopes of inspiring the next generation of security professionals looking to get into offensive security source code analysis.
What is VMWare Workspace One Access?
Per VMWare’s marketing materials:
Workspace ONE Access, (formerly VMware Identity Manager), provides multi-factor authentication, conditional access and single sign-on to SaaS, web and native mobile apps.
VMWare Workspace One Access is a large enterprise Java application and is made up of multiple components. As usual when assessing large enterprise applications, it is critical to understand how the routing of servlets work.
In this case, VMWare Workspace One Access makes use of the Spring Framework. So while we can use the <span class="code_single-line">web.xml</span> file to understand the prefix for certain paths, further analysis in the code must be done to discover the full endpoint URLs.
There are a number of applications bundled up in VMWare Workspace One Access, but for this blog post, we’re going to be focusing on the <span class="code_single-line">SAAS</span> application.
Taking a look at the <span class="code_single-line">web.xml</span> file inside <span class="code_single-line">webapps/SAAS/WEB-INF/</span>, we can see the following mapping:
In order to find the actual mappings for a Spring application, we suggest you look for valid controller classes and assess how the endpoints are declared.
For example, in this case, we can pick <span class="code_single-line">webapps/SAAS/WEB-INF/classes/com/vmware/horizon/rest/controller/AuthenticationController.java</span> and we can see that routes are declared in the following fashion:
These annotations are referred to as decorators. Decorators are a common programming paradigm in many languages.
You can map these <span class="code_single-line">RequestMapping</span> values by combining them with the prefixed path found in the <span class="code_single-line">web.xml</span> in order to reach this functionality. Once you understand this concept, it becomes straight forward to hit the codepath you would like to hit for Spring applications.
Sometimes this can be more complex, where there is a root controller route mapping i.e. <span class="code_single-line">/system/</span> and children routes underneath, albeit, this is not too difficult to work out once you are iterating through the source code.
Now that we have a basic understanding of how the routing works for the <span class="code_single-line">SAAS</span> component of this enterprise application, we have a few options.
1) We can audit each and every controller, looking for dangerous functionalities and assessing the access controls along the way.
2) We can specifically search for dangerous functions and trace them back to the originating controller.
In our opinion, either strategy is an acceptable option when auditing large applications, however we do prefer to look for dangerous functions first before deep diving into each and every controller.
Often in source code auditing, we talk about discovering sources and sinks. I’ve found that developers often don’t understand what we mean by finding sources and sinks, even though, they have probably done some sort of similar analysis in their careers without knowing the name for it.
As usual, we searched for functionality that performs object deserialization, file operations, string concatenation, SQL queries, and HTTP clients.
It’s important to note that when searching for dangerous functionality, try and understand the pre-requisites for the dangerous functionality to exist and then search for those.
For example, for server-side request forgery to exist, there must be a HTTP client somewhere that is being used. Try and discover each and every HTTP client that gets declared and trace it back to where it is being used.
What we’re about to describe is the process of starting at a sink and working backwards to the source.
Our search for HTTP clients was fruitful, leading to the discovery of this snippet of code:
We can see that the function <span class="code_single-line">getStatusFromRemoteHost</span> is responsible for making a HTTP request with an <span class="code_single-line">Authorization</span> header containing a signed token.
Now naturally, we ask the question, how is <span class="code_single-line">getStatusFromRemoteHost</span> called?
An attacker can provide a path variable containing <span class="code_single-line">@example.com</span> and a http request is being made to <span class="code_single-line">https://<hostname>@example.com</span>, ultimately, to example.com instead of the hostname.
Since there is no forward slash after the hostname, an @ character can be injected to control the server being requested.
In order to exploit this bug, you must know the cluster hostname. This can simply be guessed, or it can be obtained from <span class="code_single-line">/SAAS/jersey/manager/api/system/clusterInstances?activeOnly=false</span>.
A proof-of-concept for this vulnerability can be found below:
Note, the hostName has to be the host name of the instance as registered on the local system. The path contains the exploit to request an arbitrary URL through the injection of the @ symbol and an arbitrary hostname.
The full HTTP response for the maliciously requested URL will be returned:
This will send a HTTP request to attackercontrolledhost.com containing the Authorization header / admin token.
VMWare dealt with these issues seriously, and we appreciated their efforts in remediating this vulnerability and corresponding with us.
We reported this issue to VMWare on the 5th of October, 2021.
The timeline for disclosure can be found below:
Oct 5th, 2021: Disclosure of account takeover via post auth SSRF
Oct 5th, 2021: Response from VMWare confirming receipt of vulnerability
Nov 9th, 2021: Assetnote Security Research team requests an update on the issue
Nov 12th, 2021: Response from VMWare confirming that vulnerability is being worked on
Dec 8th, 2021: Assetnote Security Research team requests an update on the issue
Dec 8th, 2021: Response from VMWare confirming they could reproduce SSRF but not admin token disclosure on latest version of Workspace One Access
Dec 10th, 2021: Response from VMWare confirming progress is being made on fixes
Dec 17th, 2021: VMWare publishes advisory
The remediation details provided from VMWare’s advisory are satisfactory and will ensure that this vulnerabilty cannot be exploited. The knowledge base article detailing the patches or workaround to apply can be found here.
Due to the lack of a slash character, it is possible for an attacker to make HTTP requests to arbitrary origins and read the full response. Furthermore, an authorization header gets leaked and hence it is possible for an attacker to weaponize this vulnerability to steal the authorization header of an admin upon viewing an image or making a single click.
As part of the development of our Continuous Security Platform, Assetnote’s Security Research team is consistently looking for security vulnerabilities in enterprise software to help customers identify security issues across their attack surface.
Looking at this research as a whole one the of the key takeaways is that the visibility into the exposure of enterprise software is often lacking or misunderstood by organizations that deploy this software. Many organizations disproportionately focus on in-house software and network issues at the expense of awareness and visibility into the exposure in the software developed by third parties. Our experience has shown that there continues to be significant vulnerabilities in widely deployed enterprise software that is often missed.
Customers of our Attack Surface Management platform were the first to know of this vulnerability and others like it. If you are interested in gaining wholistic, real-time visibility into your attack surface please contact us.
Assetnote Is Hiring!
If you are interested in working on the leading Attack Surface Management platform that’s helping companies worldwide from the Fortune 100 to innovate startups secure millions of systems please check out our careers page for current openings. We are always on the lookout for top talent so even if there are no open roles in your field please feel free to drop us a line.
Your subscription could not be saved. Please try again.