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
view sourceprint?
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
CyberOne’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, CyberOne
March 20, 2019