Parallels RAS (Remote Application Server) is a virtual desktop infrastructure (VDI) and application delivery solution that enables an organisation’s employees and clients to access and use applications, desktops and data from any device, thanks to the virtualisation capabilities that it offers.
A few weeks ago I published my discovery of this vulnerability, classified as CVE-2020-35710, associated with this architecture. In this article I explain exactly what it is.
RAS Architecture
The following figure shows a scenario where the RAS Secure Gateways HTML5 Portal is deployed in the DMZ. The RAS Secure Gateway will forward requests via HTTP to a remote desktop session host, RAS RD, which will have the Remote Desktop Services (RDS) functionality installed. As can be seen, the RDP host is located within the organisation’s LAN, although it could also possibly be located within a DMZ, thus reducing the exposure surface of the organisation’s internal network assets.
Parallels Remote Application Server Search
Finding Internet-accessible HTML5 Gateway RAS devices is relatively easy. Simply consult a device administration guide to be able to extract patterns from URLs.
As can be seen in the image, the access URLs to these devices have the “/RASHTML5Gateway/” and “/RASHTML5Gateway/#/login” singularities, which makes it much easier to locate the access form of these connected devices on the Internet by doing a little bit of Search Engine Hacking.
It can be seen that, without much effort in performing a dorking, Google offers a good number of results related to the HTML5 form of access to the web portal of the devices.
Analysis of HTTP Traffic Generated by Parallels RAS
One of the most important aspects of any pentest or audit related to web systems of any kind is to analyse HTTP requests and responses to see if the device reveals interesting information that, at first glance, and without the help of an HTTP proxy, might go unnoticed. To do this, select one of the results returned by Google and observe that the RAS form requests in the login field a centralised Active Directory user (user@domain) and a password.
Using ZAProxy, it can be seen that by clicking directly on the login button, without the need to enter a user@domain with password, the RAS Secure Gateway generates an HTTP request by POST to the RAS RD where it displays its IPv4 address.
If the RAS RD is located in the organisation’s internal network, the organisation’s IPv4 addressing space would be exposed. Ideally, if the RAS RD is located in a demilitarised zone (DMZ), its IPv4 addressing space would be exposed.
How to Minimise Information Leakage
Based on the information provided by the manufacturer, it is possible that the RAS Secure Gateway could perform the functions of the RAS RD within the same machine. As the machine is the same, all HTTP requests to the virtualised resources could be made on localhost. The result for this scenario would be as follows:
The IPv4 address of the RAS RD would not be disclosed, but the TCP ports related to the RAS Secure Gateway service (8080/TCP) and the RAS RD (8081/TCP) are being disclosed.
In the case that the RAS Secure Gateway and the RAS RD are in different networks, it seems very complicated to eliminate the information leakage presented in this article, because the RAS Secure Gateway has to make an HTTP request via POST to communicate with the RAS RD.
