search menu icon-carat-right cmu-wordmark

CERT Coordination Center


SSH-1 allows client authentication to be forwarded by a malicious server to another server

Vulnerability Note VU#684820

Original Release Date: 2001-01-18 | Last Revised: 2001-10-29

Overview

A design flaw in the SSH-1 protocol allows a malicious server to establish two concurrent sessions with the same session ID, allowing a man-in-the-middle attack. The client must accept unknown host keys from the malicious server to enable exploitation of this vulnerability.

Description

SSH-1 authentication relies on the uniqueness of each SSH server's public host key. This key and a corresponding private key are computed by each server for its own use. Since there is a pseudorandom element in the computation of the keys, it is extremely unlikely that two servers would compute the same key pair.

Servers share their public keys with other hosts, so a server could steal another server's public host key. However, if a server used another server's public host key as its own, it would also need the corresponding private key to decrypt messages from its clients. The private key is not shared and is very difficult to compute from the public host key alone.

In SSH-1, a session ID is computed as a hash of the server's public host key and a 64-bit random number called a cookie. The SSH-1 protocol assumes that:

1. no two servers have the same public and private host keys, and
2. that, given any public host key and 64-bit random number, it is very difficult to find a different public host key and/or cookie which yield the same session ID.

SSH-1 relies on the above assumptions during authentication. In the SSH-1 authentication process, the server generates a 256-bit random number called a challenge. The challenge is then encrypted with the client's public key, so that only the client can decrypt it. The client receives the encrypted challenge and decrypts it. The client returns the challenge response: an MD5 hash of the concatentation of the challenge and the session ID. The server independently computes the expected challenge response by the same formula. If the client's challenge response matches what the server computed, then the server responds that client has successfully authenticated.

Public key encryption of the challenge protects the challenge from discovery by third parties as it is sent from the server to the client. Furthermore, the MD5 hash prevents third parties from discovering the challenge from the client's challenge response to the server. Assuming that neither host has been compromised, only the server and the client will know the challenge.

The inclusion of the session ID identifies the challenge response with a certain server, since the session ID is derived from the server's public host key. Different servers should have different host keys, which produce different session ID's and change the expected challenge response. This difference in session ID's prevents a malicious server from replaying a client's challenge response to another server to authenticate as the client.

Unfortunately, a weakness has been discovered in the formula for computing a session ID from the server's public key. This discovery allows modification of a server's public host key without changing the derived session ID. Furthermore, the modified key is often much weaker than the original, so it is easily factored to create a corresponding private key. This new key pair can be used to negotiate multiple concurrent SSH connections with same the session ID.

Therefore, assumption 2 above, upon which the security of SSH-1 authentication is grounded, does not hold. As a result, authentication in SSH-1 is vulnerable to man-in-the-middle attacks.

Impact

Attackers can obtain victim user priviledges on other hosts running an SSH-1 server.

Solution

Upgrade to SSH-2, which is not vulnerable to this attack.

When using SSH-1, be careful when accepting unknown server keys for SSH connections. Clients should not attempt to start an SSH-1 connection with encryption disabled. Servers should refuse SSH-1 connection requests which have encryption disabled.

Vendor Information

684820
Expand all

SSH Communications Security

Updated:  February 06, 2001

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenSSH

Updated:  October 29, 2001

Status

  Not Vulnerable

Vendor Statement

See http://www.openssh.com/security.html.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A

References

Credit

The CERT/CC would like to thank Antti Huima, Tuomas Aura, and Janne Salmi for their analysis and Tatu Ylonen for bringing this vulnerability to our attention.

This document was written by Jeffrey P. Lanza and Shawn Van Ittersum.

Other Information

CVE IDs: None
Severity Metric: 1.16
Date Public: 2001-01-18
Date First Published: 2001-01-18
Date Last Updated: 2001-10-29 15:52 UTC
Document Revision: 33

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.