32

When SSHing to a host that has been compromised (or outright replaced using the stolen server keys) by an attacker with root permissions, what is the worst that can happen to the client?

It is well known that X forwarding poses some risks, and agent forwarding is obviously a bad idea in that scenario, but are there more issues?

  • What information can be gained about the client, in addition to environment variables set by ssh (SSH_CONNECTION, everything from ~/.ssh/environment)?
  • What can be accomplished with terminal escape sequences?
  • How hard is it to fake a logout (in response to CTRL+D, logout etc.) to the client, thereby provoking a user to execute additional commands with potentially sensitive inputs on the remote host, like sudo with a password entry? Can the client's prompt be read remotely to make such a deceit more convincing?
  • Are there any effective ways to prevent such deceit, like aliasing ssh to "ssh; echo somesecret"?
Community
  • 1
lxgr
  • 4,114
  • 3
  • 29
  • 37

2 Answers2

17

Intercepting the "logout" commands is easy on the hostile server. Intercepting the "Ctrl-D" requires taking control of the terminal in raw mode, but that's not a big issue.

Reading back the terminal contents might prove difficult. Different terminals implement their own set of control sequences; xterm is notorious for implementing a lot of them. I don't see any sequence which allows reading back the terminal contents; however, some considerable messing up can still be done with the sequences, such as moving the window around, switching fonts, and so on. In older days, it was possible to actually make xterm create local files, albeit without much control on the file name (I don't remember the details, but it was probably with the "log files" feature which may be disabled at compile-time). Besides dancing, an xterm could be made to sing, too, with the "bell character" -- it is more a nuisance thing than an attack vector, though.

Speaking about nuisance: depending on the client system and its configuration and graphic drivers, a rogue terminal scrolling text at high speed may all but freeze the victim's console (in my experience, gnome-terminal and a compositing window manager can turn into a bad combination for that).

Still in xterm, there are sequences to manipulate the clipboard (search for "manipulate selection" in the reference page linked above). This can be nasty, both for reading and for writing. See this page for a discussion about the possible issues (an issue-tracking list of comments, from people discussing the possibility of importing that mechanism in a terminal emulator called mintty).

The overall conclusion is: do not SSH into insecure hosts. If you do, you may want to do that from rxvt-unicode, an rxvt fork where the author made (among other features) some effort at disabling "insecure" control sequences by default (they can be brought back with the "-insecure" command-line parameter).

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
2

If you disable X11 Forwarding and SSH Agent forwarding (at least on Ubuntu 18.04 this is the default config), the remote root can do nothing that they already cannot do on that host without you connecting to it with ssh. (Of course, if remote root knows about some security vulnerability in your ssh software, it's possible to take over your client and execute code as your account on your machine. This is identical to any software you use to connect any remote machine.)

Examples of things that remote machine process running as root (e.g. remote machine administrator or any process running on his or her behalf):

  • Read and modify any file you access, read or write.
  • Fake results of any system call of any process including changing any arguments, running nothing or something else or forging the return value.
  • Read and modify memory of any of your processes.
  • Take control of any open TCP/IP connections running on said machine.
  • Monitor and modify any events (e.g. every keystroke you hit that is plain text visible on the remote machine by even a one process).

Examples of things that remote machine process cannot do:

  • Read plain text contents of encrypted pipes running through that machine where the encryption is happening outside the remote machine (e.g. P2P encrypted traffic).
  • Read contents of encrypted files if you haven't stored encryption keys on the remote machine as files or as part of the RAM. For example, if you encrypt files on your own computer and copy those to remote machine using ssh/scp.
  • Read the contents of your local environment (including prompt settings) unless you've configured ssh to forward such settings to remote hosts. (For example, to get familiar prompt style on all machines.)

The only way to force logout / disconnect is to use escape character in ssh settings. By default this is supposed to be ~ and if you press enter, ~, . in sequence the ssh will detect this escape sequence and close the connection. The remote host cannot prevent escape character sequences. Behavior of any other key sequences can be faked. Note that in case ~ has been configured as "dead key" as with Finnish keyboard you have to enter the escape sequence as enter, altgr+~, space, . or enter, altgr+~, altgr+~, .. I think US international keyboard config will behave the same. Note that if you use ssh to connect host-a and connect from there to host-b, using the above escape sequence will kill the connection to host-a because the escape sequence will be interpreted by the ssh process that first gets to read the input (in this case, the ssh process running in localhost with connection to host-a). If you need escape sequences to disconnect from each host, every host connection must use separate escape sequence. Obviously, if host-a is under attacker control, he or she can modify any attempt to use any sequence of characters. See man ssh and subtitle "ESCAPE CHARACTERS" for more information or try enter, ~, ? with active ssh connection.

Mikko Rantalainen
  • 513
  • 2
  • 11