RoyalTS SSH Tunnel - Authentication Bypass [CVE-2020-13872]

Tempo di lettura: 7 minuti

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.

SSH Settings for the connection with the target host
SSH Settings for the connection with the target host
Settings for the usage of the Secure Gateway
Settings for the usage of the Secure Gateway
Secure Gateway Settings aka the tunnel settings
Secure Gateway Settings aka the tunnel settings
Credentials used for the tunnel
Credentials used for the tunnel
Royal Server Settings installed on the bridge host
Royal Server Settings installed on the bridge host

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

SSH connection opened through the tunnel
SSH connection opened through the tunnel
But, if we look at the active connections on my host (Host A), we can see that RoyalTS.exe is open on 0.0.0.0 and anyone in my network could exploit the tunnel without authenticating to the Secure Server

The service is listening on 0.0.0.0
The service is listening on 0.0.0.0

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.

All ports are closed
All ports are closed

After the creation of the tunnel, we can see the open port.

The port 59349 is now open
The port 59349 is now open

Imagine a situation where a developer has a lot of open tunnels, like this

Three opened tunnel, on ports 59349,59381 and 59384
Three opened tunnel, on ports 59349,59381 and 59384

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;
Three ssh connections for the three hosts
Three ssh connections for the three hosts

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

SSH connection established
SSH connection established

In the bridge connections I will not appear

Only one tunnel opened, instead of two
Only one tunnel opened, instead of two

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