RoyalTS SSH Tunnel - Authentication Bypass [CVE-2020-13872]
Tempo di lettura: 7 minutiData pubblicazione: June 8, 2020
Description
During a recent assessment I had to use the software in question (RoyalTS v4.3.61328 for Windows) to reach some servers via port forwarding. The software uses a “Secure Gateway” to create an authenticated tunnel (created by Royal Server), installed on a bridge server. Once installed, all you have to do is create an SSH connection to the target server and enter the IP address of the bridge server as Secure Gateway.
The problem is that, once a SSH tunnel is created on the bridge host with a Secure Gateway, this tunnel will listen on the address 0.0.0.0 on the port opened ad hoc by RoyalTS (higher than 50000), leaving the possibility for anyone to exploit the tunnel without having to authenticate to it.
For example, if I want to connect to the Host C, through the Secure Gateway (Host B), RoyalTS would create a tunnel with the Royal Server on the Host B and open the SSH connection with Host C, as in the image below
If we look at the settings, we can see that the section “Remote Ports accept Connections from other Hosts" is disabled
Impact
An attacker, within the same network as host A, with a simple port scan, can immediately notice that non-standard ports are open. Before tunnel we’ve got the following situation, where 192.168.25.1 is the IP address of the target host A.
After the creation of the tunnel, we can see the open port.
Imagine a situation where a developer has a lot of open tunnels, like this
An attacker could easily find the open ports, where each of which refers to one host:
- 59349 for the first;
- 59381 for the second;
- 59384 for the third;
The attacker could easily bruteforce the ssh login, or, even worse, if the servers aren’t patched and, for example, the service RDP is open, he could use some known exploits, like BlueKeep.
Another example could be:
I’m in a library with RoyalTS v4 opened with a tunnel (authenticated) and a connection throught telnet (or ssh) with no credentials into host C.
Another person (the attacker), connected into the same network, could see the open port of my pc (with a port scan) and use that tunnel (with no authentication, because it’s established yet) to connect throught telnet (or ssh) and gain access to the host A.
If the host A has authentication, the attacker obviously need to bruteforce it or to exploit it, but the vulnerability is that the tunnel, that is listening on 0.0.0.0, is open to everyone withouth the authentication.
Also, if I connect to the host C on port 59349 exploiting the vulnerability
In the bridge connections I will not appear
Conclusion
If you are using a version prior to v5, I suggest to update immediately to the major release. The vulnerability is confirmed for the Windows application, however is possibile that the Royal TSX < 4 (for Mac) is affected too.
CVSS 3.1 Vector: AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:L
Risk Score: 8.8
Timeline
- 04-Jun-2020 - Reported to vendor
- 04-Jun-2020 - Vendor replied that it’s a known bug and it’s fixed on the last major version
- 06-Jun-2020 - CVE-2020-13872 assigned
- 08-Jun-2020 - Public disclosure