Written By David Roccasalva, Senior RED Consultant
Not long ago, I assisted a client of ours with a penetration test of their VMware Horizon remote access solution and discovered a vulnerability affecting how it handles Multi-Factor Authentication (MFA). As a result, with a compromised user account password, I could gain access to the organisations internal network from the internet, bypassing the MFA requirement. In this blog, I’ll provide a high-level summary and explain how I identified and exploited the vulnerability.
VMware released a security advisory for this issue, which can be found here.
Product Details
VMware Horizon is a “Desktop as a Service” solution providing organisations with the ability to deploy virtualised desktops and applications. Similar to the likes of Citrix, VMware Horizon is commonly used as a way to provide staff with remote access to the internal network. For example, this could be staff working from home or internal IT administrators accessing segregated network environments.
Affected Product Version(s)
VMware Horizon DaaS versions 7.x and 8.x.
High-Level Summary
As with any remote access solution, it is typical for users to authenticate with multiple credentials such as a username and password along with a second factor of authentication such as a One-Time Password (OTP) from a mobile authentication app, SMS, email or hardware token.
The use of multi-factor authentication provides an extra safeguard to ensure that access through the external perimeter is well protected and that if a password is compromised, there is an additional control as a last line of defence. These systems are generally high-value targets for attackers, seeking to gain unauthorised access into an organisations environment.
It was found that VMware Horizon version 8.x contained a broken authentication vulnerability, that was in the end, trivial to bypass. Exploiting this vulnerability resulted in me gaining access by only providing a valid username and password and bypassing the OTP/MFA check.
Now yes, in this case I already had test credentials for the purpose of the penetration test. But there is a myriad of ways in which the bad guys can acquire such details. For example, phishing staff to trick them into divulging credentials, exposing them through third-party data breaches and/or credential stuffing attacks just to name a few.
Vulnerability Exploitation
VMware Horizon has two “portals” for authentication, one that is used by the installable application client, and the other for web-based access. (The former can also be used for web-based access.)
While they both use different methods to authenticate, they were affected by the same underlying issue and the OTP check in both could be bypassed.
As mentioned above, this writeup is from the perspective of an attacker already having obtained a valid set of credentials. I won’t be covering methods on how these could be obtained. Depending on the configuration, you would need:
- The Windows domain name (if applicable)
- Username
- Password
What I will demonstrate though, is how you could (depending on the configuration) obtain the Windows domain name from the VMware Horizon web application. The VMware Horizon server uses a REST API for various functions, one of those API endpoints can be queried as an unauthorised user to identify the internal Windows domain. You can simply view this by using navigating to:
For example, if we look at the following VMware Horizon demo site, we can find the domain name “VMWTD”. (I’d recommend blocking unauthorised users for querying that API endpoint):
Bypass #1 (Horizon default primary login portal)
The first bypass is via the default login portal that is typically accessed via the installable client and via the /appblast/webclient/index.html URL.
When MFA is enabled in VMware Horizon, that user must first provide their username and the OTP code, followed by their domain password. If the username and/or OTP code is incorrect, the user receives an access denied message.
The below depicts the first HTTP POST request made to the server with the username and passcode highlighted:
If the first factor of authentication is successful, the user is then presented with a second screen to provide a valid domain password:
However, if an attacker intercepts the initial request of the username and OTP code and instead provides the correct XML variables for domain credentials, if they are valid, the system authorises the user without requiring a valid OTP. This is the same as effectively “skipping” the first step and only providing a valid username and password.
The OTP check can be bypassed by simply providing the “windows-password” XML entities first with a valid username and password:
If the credentials are valid, the server provides a valid session token to access the VMware Horizon system:
Bypass #2 (“Legacy” portal)
Similarly, the same method can be applied to the secondary “legacy” portal that is typically available at /portal/index.action.
This follows the same process as the previous example where the user submits their username and OTP code on the first screen, followed by their domain password on the second screen. However, this uses different endpoints and parameters to the primary web portal as depicted below:
Similarly, to exploit this, an attacker can simply skip the first POST request and submit a valid username and password to the /loginPassword.action endpoint, bypassing the initial /radiusLogin.action OTP check.
For example, the first screen can be submitted with a valid username and “fake” passcode such as “1337”:
This request can be intercepted and changed to point to loginPassword.action over the radiusLogin.action endpoint with the body of the request containing valid domain credentials as below:
As a result, this authorises the user into the VMware Horizon system without providing a valid OTP.
Remediation
There are no recommended workarounds other than upgrading your VMware Horizon instance to at least version 8.0.1 Update 1. While I did not specifically test Horizon version 9.x, VMware believes this version is not vulnerable.
Disclosure Timeline
06/05/2020 – Vulnerability discovery
06/05/2020 – Discussions with affected Privasec client and their managed service provider
07/05/2020 – Notification to VMware’s security advisory team
26/05/2020 – Demonstrate vulnerability to VMware’s R&D and security team
24/06/2020 – Privasec client is issued a hotfix from VMware to address the vulnerability
06/07/2020 – Vulnerability is retested and confirmed to be mitigated
22/09/2020 – VMware VMSA-2020-0021 security advisory published