1

Kerberos clearly keeps an attacker from getting a user's credentials in an SSH man-in-the-middle scenario (one where the attacker has gotten the user to trust their server's public key and redirects traffic through that server). However, what if an attacker is okay with not getting the user's credentials because they'll be able to listen to the session after authentication and potentially get valuable information, including subsequently entered credentials.

To be clear, here is the scenario:

  1. SSH server (Server1) and client (User1) are set up for Kerberos. Server1 has standard public/private key pair for authentication, etc.
  2. User1 initially attempts to connect to Server1 but their connection is redirected by an attacker to Server2.
  3. User1 doesn't look closely at the public key from Server2 that is presented and accepts it as a known host key for Server1 (thus setting up the MITM).
  4. User1 goes through Kerberos authentication with Server1 through Server2 (Server2 sets up two separate SSH sessions and passes information between them). Attacker doesn't gain any valuable information during authentication because of the way Kerberos works.
  5. Once authenticated, however, User1 starts performing operations on Server1, including sudo. Attacker is able to see all of the contents of the session as they pass through Server2.

Would this work? This scenario would obviously be thwarted using public key authentication during the authentication step. But is there something in the Kerberos or SSH protocol that would prevent this situation?

  • 1
    Please investigate the service ticket concept in Kerberos which is designed to prevent man in the middle attacks. – HBruijn Nov 24 '14 at 22:52
  • Thanks for your response and suggestion. I've spent some more time studying the session ticket. The IP_List item (which identifies the IP address of the client) in the session ticket would ensure that the server could detect that a third party is in the middle of the communications. Correct? If so, since that is an optional field, and not used by default for Windows, would that mean that the attack above is possible for implementation that don't enforce IP_list use? Thanks again for your help. – Bubba Nov 25 '14 at 15:24
  • The client requests a service ticket for server1 from the ticket granting service on the KDC and presents that when it tries to access Server1. Server2 can't validate that ticket, because it is encrypted with the the key for Server1. In the WikiPedia protocol description the Client_Service_Request will fail on step 2. – HBruijn Nov 25 '14 at 15:38
  • Again, Server2 is simply passing the ticket through to Server1 and NOT attempting to compromise those credentials. The attacker is interested in being in the middle AFTER authentication so that he/she can see the information passed between client and server after the authentication, such as additional credentials entered for elevated privileges. Does Server2 need to validate the ticket in this case or can it simply pass the entire Kerberos exchange unmodified to client and server? – Bubba Nov 25 '14 at 15:49
  • Ah! So basically you're assuming that you can replay the Kerberos ticket exchange after stripping the SSH encryption. AFAIK rfc 4121 the Kerberos GSS-API spec which is used by SSH has the Channel Binding Information as part of the authenticator message: "The channel binding tags are intended to be used to identify the particular communications channel for which the GSS-API security context establishment tokens are intended, thus limiting the scope within which an intercepted context establishment token can be reused by an attacker." – HBruijn Nov 25 '14 at 17:03
2

A bit expanded from the discussion in the comments:

Your question is: if you divert the SSH traffic from the client to a rogue SSH server, can that be used in a replay attack by capturing and forwarding the clients Kerberos ticket by the rogue SSH server to the real Server1?

This relies on the SSH security mechanisms preventing MiTM attacks failing, i.e. the client has not cached the real server key from Server1 yet or if it has, StrictHostKeyChecking has been disabled or ignored.

Since SSH + Kerberos GSS-API rely on SSH for the data encryption your assumption is that the man-in-the-middle rogue SSH server can, if authentication to Server1 is successful, access all transmitted information, since SSH doesn't use Kerberos based data encryption on top of the SSH encryption.

Yes, that would work in theory, but only if the your rogue SSH server, Server2, is successful in impersonating the client to Server1.

I think that the real Server1 would reject (or at least should) reject the forwarded credentials. As part of the Kerberos authentication, the client sends two messages, the Service ticket and the Authenticator. Although a forwarded service ticket is valid, the accompanying authenticator would not be.

RFC 4121 the Kerberos GSS-API spec which is used by SSH has the Channel Binding Information as part of the authenticator message:

"The channel binding tags are intended to be used to identify the particular communications channel for which the GSS-API security context establishment tokens are intended, thus limiting the scope within which an intercepted context establishment token can be reused by an attacker."

I.e. The Authenticator message includes the sender's ip-address and source port, as well as the destination ip-address and port numbers. If those don't match those of the actual connection, the Kerberos exchange should be rejected by Server1.

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.