Background: 
While conducting a penetration test of a client’s external network, I discovered three separate instances of information disclosure in VMware’s Horizon Access Web Portal. An unauthenticated user could access information such as internal domain names, the Connection Server’s internal hostname, or the gateway’s internal IP address.

Version Tested
4.7.0

CVE Number
CVE-2019-5513

Security Advisoriess
VMSA-2019-0003 – https://www.vmware.com/security/advisories/VMSA-2019-0003.html

Issue 1:
The application generates an XML file that discloses the internal hostname, authentication type, and internal domain names.

The XML file was observed in the response to a POST request at the following URI: https://$HOST/broker/xml

 

HTTP POST Request:

POST /broker/xml HTTP/1.1

HOST: [REDACTED]

Accept-Encoding: gzip, deflate

Accept: */*

Accept-Language: en

User-Agent: Mozilla/5.0 (X11; Linux i586; rv:31.0) Gecko/20100101 Firefox/31.0

Content-Type: application/x-www-form-urlencoded; charset=UTF-8

X-Requested-With: XMLHttpRequest

Connection: close

[SNIPPED]

Below is a screenshot of the XML document that is returned in the HTTP Response showing in plaintext the internal hostname (highlighted in red), authentication type (highlighted in green), and internal domain names (highlighted in purple).

 

Issue 2:
Upon interacting with the web portal, the application sets a cookie called “clientinfo” that has Base64 encoded data which includes the internal IP address of the server running the VMware application as well as the user’s external IP address.

The “clientinfo” cookie was observed in requests at the following URIs:

• https://$HOST/broker/xml
• https://$HOST/portal/info.jsp
• https://$HOST/portal/webclient/locale/en.json

The screenshot below shows the Base64 encoded cookie value in a POST request from the tool Burpsuite.

 

 

This is the cookie value data after Base64 decoding it:

{"acceptLanguage":"en-US,en;q=0.5","clientVersion":"4.7.0","logLevel":"2","clientIPAddress":"0.0.0.0,127.0.0.1","contextPath":"/portal","os":"linux32","installerLink":"https://www.vmware.com/go/viewclients#linux32"}

The actual values have been censored for confidentiality, but to explain further the user’s (in this case me) external IP address is represented by the value 0.0.0.0 and the host’s internal IP address within the client’s network is represented by the value 127.0.0.1.

 

Issue 3:
The application generates a JSP file that discloses the same internal IP address as the “clientinfo” cookie; however, the HTTP response shows the information in plaintext.

The JSP file was observed in the Response to a GET Request at the following URI:

• https://$HOST/portal/info.jsp

HTTP GET Request:

GET /portal/info.jsp HTTP/1.1

Host: [REDACTED]

Accept-Encoding: gzip, deflate

Accept: */*

Accept-Language: en

User-Agent: Mozilla/5.0 (X11; Linux i586; rv:31.0) Gecko/20100101 Firefox/31.0

[SNIPPED]

Connection: close

 

HTTP Response:

HTTP/1.1 200 OK

Content-Type: application/json;charset=ISO-8859-1

[SNIPPED]

{"acceptLanguage":"en-US,en;q=0.5","clientVersion":"4.7.0","logLevel":"2","clientIPAddress":"0.0.0.0,127.0.0.1","contextPath":"/portal","os":"linux32","installerLink":"https://www.vmware.com/go/viewclients#linux32"}

While this information disclosure may not seem to be a critical finding on its own to some, the information gathered from this can assist in planning further attacks.

I have edited the data in this article for confidentiality but kept the same overall idea. As a pentester, there are times that you have to make educated guesses, one of those being the internal domain naming schema, and sometimes you get lucky. But in this case, I did not have to guess (really lucky!).

Armed with the data from this vulnerability a malicious actor can performing an automated password spraying/brute force attack against external applications that connect to an organization’s Active Directory for authentication, all while knowing that the domain information is correct.

Less guesswork on an attacker’s part means less traffic has to go from their machine to the target. Lower traffic rates help attackers fly under the radar so as to not set off any alarms or lockout accounts, which ultimately can increase an attacker’s chances to successfully compromise accounts with no one being the wiser.

 

Remediation

See the VMware Security Advisory VMSA-2019-0003 at the following URL for information regarding affected products and patching/updating to remediate the vulnerability.
https://www.vmware.com/security/advisories/VMSA-2019-0003.html

 

Other Information

CRITICALSTART’s TEAMARES penetration testing team followed responsible disclosure procedure by submitting the vulnerability to VMware’s Security Response Center and waiting for a patch to be released for the affected devices before publishing any information.

The vulnerability was also disclosed independently to VMware by security researcher HD Moore of Atredis Partners at a later date.

 

Timeline
2018-09-25 – Vulnerability Discovered
2018-09-26 – Vendor Disclosure and Reply
2019-03-14 – Vendor Patch Released
2019-03-15 – Vendor Security Advisory Published

 

by Cory Mathews | TEAMARES, CRITICALSTART
March 20, 2019