3

I'm aware that SSH keys can be taken from a client's memory. However, in the case of SSH that requires a second factor like Duo/Yubikey stealing the key would not be enough. Could an attacker with full access (RAT, with elevated privilege) steal an existing open ssh session from memory?

And if not, why not?

(if needed for this example lets say the client is running the latest MacOS and the server is running the latest version of Ubuntu, etc.)

  • SSH is a specific implementation of a secure channel. The underlying assumption is that data is transferred between two trusted endpoints. When you state "an attacker with full access" you violating this basic assumption. In such circumstances there is no way to keep any information confidential from the attacker, and that includes symmetric encryption keys used to protect the data. – Kirill Sinitski Jan 11 '17 at 21:18
  • > "When you state "an attacker with full access" you violating this basic assumption" I don't think I am, per the premise of my question. The question can be rephased into this: Is 2FA on SSH and effective measure to prevent an attacker that owns a client gain access to the server? – seanieb Jan 11 '17 at 22:16
  • 1
    @seanieb: If the attacker owns the client, they can install a custom ssh binary. When the user connects using that modified ssh and provides his credentials, the ssh process itself can inject attacks in between the user's own commands, read from more than one pty, etc. – Ben Voigt Jan 11 '17 at 23:05
  • 1
    @seanieb: You need to do a better job of defining what "stealing the SSH session" means. Do you mean use it from another process on the same computer? From another computer in a position to MITM and steal traffic addressed to the first? – Ben Voigt Jan 11 '17 at 23:27
  • 1
    Well, the SSH session keys are good for that single TCP connection. For a new TCP connection, the server will generate new nonces and all the anti-replay features of SSH kick in. So it really boils down to: if and only if the attacker can hijack the TCP connection, he can use the stolen session to access the server. The details of moving a TCP socket from one process to another are OS-specific, but sockets don't have process affinity in any POSIX OS, because they can be used from multiple processes at once if inherited during fork. So that part is hard but not impossible. – Ben Voigt Jan 11 '17 at 23:53
4

The attacker gets the session keys and other state information from memory, but those keys are good only for that single TCP connection. For a new TCP connection, the server will generate new nonces and all the anti-replay features of SSH kick in.

So the attacker needs to hijack the TCP connection, which the server identifies by client IP address, client TCP port, and sequence number information. The attacks can be classified by how far from the original client the seized TCP connection is picked up:

  1. In the ssh process itself. If the attacker has superuser rights where ssh is running, he can either replace the ssh binary with his own compromised copy that the innocent user runs, or change its behavior via code injection (for example, injections don't modify the binary on disk, so digital signatures don't detect the tampering).

  2. In a second process on the same machine. It's easy to continue the TCP connection from here because packets sent by the server are already being routed here.

    a. All the TCP connection-related information is kept by the OS sockets layer, and while the details of moving a TCP socket between processes are OS-specific, sockets don't have process affinity in any POSIX OS, because they can be used from multiple processes at once if inherited during spawn or fork.

    b. By bypassing the sockets layer used by applications, and capturing/modifying/injecting packets at the network stack or driver -- for example using iptables or libpcap.

  3. In another machine positioned for MITM attacks. The only thing that's absolutely necessary besides getting a copy of the session keys and state itself is to continue using the same IP address so the server thinks the same TCP connection is ongoing. That's the same thing necessary for man-in-the-middle, either sitting really on the path, or at least compromising a router on the path to send packets transmitted from the SSH server to the attacker.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.