1

If a VPS running Debian 10 Xfce as a cloud desktop has been rootkit infected and there is an ongoing SSH connection with X2Go from a client to manage this server, is it possible for an attacker on the VPS to hijack the existing SSH connection in order to attack and infect the remote client?

The initial attack vector is executed in the form of browser hijacking (for instance with BeEF) on the cloud desktop, which is used as a "beachhead" to run secondary attacks and modifications on the VPS.

What security measures can be taken to mitigate such an attack and protect the client?

  • The already established SSH connection by itself is likely not a problem, although there might be in theory exploitable security issues in the client. But usually something is done with the connection, like executing commands (which have unintended results if the system is compromised), entering important information, doing some port tunneling ... . So the risk mainly depends on what exactly is done here. See also [What are the risks of SSHing to an untrusted host?](https://security.stackexchange.com/questions/38128/what-are-the-risks-of-sshing-to-an-untrusted-host). – Steffen Ullrich Aug 02 '21 at 06:00
  • The remote VPS host is installed daily from a fresh Debian snapshot, but is under the risk of browser hijacking (for instance with [BeEF](https://beefproject.com/)), which is used as a "beachhead" to run secondary attacks and modifications on the server (e.g. rootkit). In order to contain the danger of a hijacked Firefox browser in the first place, would it help to sandbox it, for instance with [Firejail](https://firejail.wordpress.com/)? –  Aug 02 '21 at 19:26
  • If the VPS can be attacked from a browser hijacking, then the risk is neither the browser nor the hijacking but a vulnerable web application at the server - which could be exploited even without a browser. Attacks like SQL injection, RFI, LFI etc are all server side problems which don't need a vulnerable client for attacking, Since the browser is not actually needed for attacking in this case, protecting the browser would not help either. Also, none of this has anything to do with SSH. – Steffen Ullrich Aug 02 '21 at 19:35
  • I think you need to include a full description of your setup (which systems are involved, which should be considered compromised, where exactly is the SSH connection ...) in your question if you want to have an answer which fits your setup. None of this you write in the comments can be derived from what you ask in the question. – Steffen Ullrich Aug 02 '21 at 19:48
  • The question has been updated with system details. Thank you! –  Aug 02 '21 at 22:42
  • Thanks for the details. Now it feels like your comment about Firefox, BeEF, Firejail etc was a distraction from your original question: in your question you ask how to protect a client against a compromised server. The BeEF.. topic is instead about how to prevent the initial server compromise - which is a completely different question. Please don't mix these things up because this only leads to confusion. – Steffen Ullrich Aug 03 '21 at 05:14

0 Answers0