3
$\begingroup$

Friday we had a disagreement with a colleague of mine about the implications of SSH server key compromission

The question was stated as this :

What could a hacker do while provided with the SSH server private key and a MitM position specifically when the client is authenticated with a public key (server configuration disallow password-based authentification)

after 20 minutes we could agree on the following facts :

  • Stream decryption (eg. Is SSH using temporary keys encrypted with both public keys ?)
  • Stream tampering (same question with HMAC keys)
    • Identity theft : (being able to tamper a root connexion and replace users public keys with the hacker's in the server ; user's private key is safe in his computer ... is it ?)
    • Identity substitution : being able to hijack the auth dialog to the compromised server and replay it in real time with an other non-compromised server auth dialog (==> hacking server A, hijaking client C connection to server A and connecting the pirate as C to the non-compromised server B)
  • (placeholder for any other ideas :) )

Can anyone help us to sort these out ?

Answer see @PauloEbermann answer below or this article http://www.gremwell.com/ssh-mitm-public-key-authentication

Improve this question
$\endgroup$
4
  • $\begingroup$ If SSH doesn't suck, the only thing he should be able to do is impersonate the server. $\endgroup$
    – CodesInChaos
    Commented Sep 3, 2012 at 11:37
  • $\begingroup$ Wouldn't impersonating the server allow a man-in-the-middle attack? Allowing the attacker to inspect every packet? Also, what do you mean by "If SSH doesn't suck"? Just curious. Thanks. $\endgroup$
    – HeatfanJohn
    Commented Sep 3, 2012 at 22:23
  • $\begingroup$ @poncho thanks for the tag : my reputation was too low to add it myself $\endgroup$
    – Cerber
    Commented Sep 4, 2012 at 8:08
  • $\begingroup$ @HeatfanJohn impersonating the server allow a man-in-the-middle attack be carefull : We accepted the fact that the hacker was already in MitM position. How we don't care, we just want to know what he could do if he manage to find the server's key $\endgroup$
    – Cerber
    Commented Sep 4, 2012 at 8:11

1 Answer 1

Reset to default
2
$\begingroup$

In the common configuration of SSH, the session keys (and a session ID) will be negotiated using the Diffie-Hellman key exchange, and then authenticated by the server, using its private key to sign all the exchanged data (which is then checked by the client).

The public key authentication of the client happens after that, when the actual connection is already running, and does not influence the encryption (and MAC). But the public-key authentication is a signature over multiple values, including the session identifier.

So, in effect, if the attacker has the server's key she can pretend being the server (to the client). She would have to accept the public key login, and show the client some shell or similar.

What does not work for the attacker is to connect at the same time (as a client) to the server and use the client's public key authentication to authenticate itself to the server, as the signature includes the session ID, and the session ID will be different for different Diffie-Hellman key exchanges.

Also, it seems not possible to manipulate the Diffie-Hellman key exhange in a way that one still knows the created keys, and they (as well as the session ID) are the same for both connections.

With RSA key exchange (where the client simply RSA-encrypts the some random data with a transient server key and sends it to the server, and both sides derive everything from this then shared secret (and the other stuff that was exchanged, like the public key, the offered key exchange methods and so on), a MiTM-attack (knowing the server's transient private key) is feasible - simply decrypt this message, then you know the keys used both for encryption and authentication (and the message-ID), and can read and modify all further messages.

If she only knows the server's long-term private key, this is not so simple: While she can replace the transient server key with her own one, this results in a different session ID (and session keys), and as such the public-key authentication of the client will not work anymore for her.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Nice answer :) thanks. So, if I summarize : under DH key exchange, the hacker can pretend to be the server but cannot do anything more. No decryption or tampering is possible... I was wrong ;) : I thought that losing the server key would lead to a worst situation. $\endgroup$
    – Cerber
    Commented Sep 4, 2012 at 12:48
  • 1
    $\begingroup$ One interesting question is, if a MitM who knows the server's private key can he execute a downgrade attack to the RSA key exchange? $\endgroup$
    – CodesInChaos
    Commented Sep 4, 2012 at 14:41
  • $\begingroup$ @CodesInChaos Well, I think that if the server admin chooses to disable RSA kex as suggested by Paulo Ebermann there is no way of downgrading $\endgroup$
    – Cerber
    Commented Sep 4, 2012 at 21:21
  • $\begingroup$ @CodesInChaos can the mitmer use RSA for client connection and DH for server connection so that he gets the same session key for both connections? $\endgroup$
    – Smit Johnth
    Commented Apr 16, 2013 at 3:01
  • $\begingroup$ @SmitJohnth No, the session keys are derived in a completely different way in both cases. $\endgroup$
    – Paŭlo Ebermann
    Commented Apr 16, 2013 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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