News

SSH1 Vulnerabilities

The purpose of this brief is to bring to light a number of the important security flaws found in the SSH1 software. For more in-depth information on these vulnerabilities, please see the Reference section of this document, which contains links to a related white paper and CERT vulnerability notes.

SSH1 (Secure Shell 1) was designed in 1995 as a drop-in replacement for insecure services such as rlogin, telnet, ftp, and the Berkeley 'r' services. As time passed, however, it became apparent that there were inherent security flaws in SSH1. These flaws include a weak hash and susceptible encryption algorithms.

These flaws, described below, fall in the following categories: access control and authentication, data integrity, confidentiality, and connection redirection.

For a complete list of vulnerabilities, please visit CERT/CC.

Access Control and Authentication

CERT VU#565052

Summary
Passwords sent over SSH1 using the RC4 cipher can be cracked if NULL passwords are disallowed on the server.

Description
This problem occurs in conjunction with CERT VU#665372. When RC4 is chosen as the cipher for SSH1 connections, and password authentication is used, an attacker can capture and playback sessions up to an hour later. Due to a unique characteristic of the RC4 cipher, and because different responses are returned upon different authentication failures, an attacker can play back a previously captured session, manipulate the password packet, and when a particular response is received, is able to determine the first character of the password. A similar procedure, with some additional steps can then be used to determine other characters in the password.

Note that RC4 was disabled from SSH Communications Security's distributions in 1997.

Solution

Do not use the RC4 cipher for SSH1 connections

Data Integrity

CERT VU#665372

Summary
SSH1 connections using RC4 and password authentication can be replayed

Description
When an SSH1 session using the RC4 cipher is established, the client and server agree upon a session key (SK), which is generated using a server key (VK) that is renewed on a regular basis (one hour by default). The server uses the first 16 bytes of SK as an RC4 key (SK1') to encrypt its traffic. However, the client does not perform this XOR operation, so it simply uses the SK2 for encrypting traffic to the server.

If the victim (client) has requested password authentication for this session, the attacker can record the victim's conversation and then replay it as long as the server key (VK) has not yet expired. Under default configurations, this presents the attacker with a one hour windows in which to replay the conversation.

Note that RC4 was disabled from SSH Communications Security's distributions in 1997.

Solution

Upgrade to SSH2

Disable RC4 and password authentication

CERT VU#25309

Summary
Because the CRC checksum used with the RC4 cipher can be modified, packets can be modified arbitrarily.

Description
When using the RC4 cipher, SSH1 uses CRC to perform integrity checks on incoming packets. Because the CRC checksum can be modified, an attacker can intercept an SSH1 packet, modify the contents, then modify the CRC to match. When the packet is then retransmitted, from the attacker to the victim, the CRC integrity check will pass. This means that the attacker can make arbitrary modifications to the packet and the victim will be unable to detect them.

For this attack to be successful, the client must be using the RC4 cipher, the server must allow the use of RC4, and compression must be not be used. Note that RC4 was disabled from SSH Communications Security's distributions in 1997.

Solution

Do not use the RC4 cipher for SSH1 connections

Connection Redirection

CERT VU#684820

Summary
SSH1 allows client authentication to be forwarded if client accepts unknown host keys.

Description
I. Preconditions:
Client accepts unknown host keys from the server.

There are three hosts:

C - the client

M - a malicious server controlled by the attacker

S - a server that the attacker is trying to gain access to

If encryption is disabled:
The client C attempts to connect to M, which prompts M to connect to S and obtain its public host key (PubKeyS). M then forwards PubKeyS to C, where a warning dialog will be displayed to indicate that the host key for M has changed. If the victim at C ignores this warning and accepts PubKeyS, the client's SSH1 software will generate a session key SessKeyC, which is encrypted in PubKeyS so that only S can decrypt it. However, because C has chosen to disable encryption, this session key won't actually be used anywhere.

Now M has an open SSH1 connection to S, but it still needs to authenticate itself. When S presents an RSA challenge (ChalS-M) to M, M forwards the challenge to C, where the victim correctly answers the challenge. At this point, M has connected and authenticated to S as the victim, gaining access to any of the victim's resources on S.

If encryption is enabled:
The attack works similarly, only M has to get hold of the session key. In order to do so, it generates a new key pair (PubKeyS*, PrivKeyS*) from PubKeyS. This operation is invariant to the session ID derived from S' public key material. M now forwards PubKeyS* to the client instead of PubKeyS, together with the original session ID that is used for agreement on a symmetric key K. C and S will succeed in negotiating K, since PubKeyS* produces the same session ID as PubKeyS. However, M will be able to intercept it since it is in possession of one of the private RSA keys matching the session ID.

The problem lies in the fact that the session ID allows for so-called false splits: the moduli of session key and host key are concatenated in a way that makes it possible to select pseudo-moduli yielding the same bit string when concatenated. If these pseudo-moduli are chosen at random, it is very likely that they are much easier to factorize because they are not products of two primes. M chooses one of the possible pairs of pseudo-keys and factorizes it in order to obtain the private counter-part.

II. Impact
Attackers can cause victims to perform authentication on their behalf.

Solution

Upgrade to SSH2 which is not vulnerable against this attack

When using SSH1, be careful when accepting unknown server keys for SSH1 connections. Additionally, do not attempt to make an SSH1 connection without encryption.

For servers, refuse SSH1 connections which have encryption disabled.

CERT VU#684820

Summary
SSH1 allows client authentication to be forwarded if encryption is disabled.

Description
Attackers in control of a malicious server can use a valid client's information to gain access to a second server that the client has access to.

Solution

Do not attempt an SSH1 connection if encryption is disabled. For servers, refuse SSH1 connections which have encryption disabled

This paper has given a brief overview of some of the known security flaws within SSH1. For more complete details, please read the information in the documents listed in the next section.

References

"Fatal Vulnerabilities in SSH1," Antti Huima, SSH Communications Security Oyj.
CERT vulnerability notes: www.kb.cert.org/vuls

SSH Corp. Contact
George Adams
SSH Communications Security Corp.
Tel: +1 781 247 2100
E-mail:

Americas Contact
Byron Rashed
SSH Communications Security, Inc.
Tel: +1 650 251 2721
E-mail:

Europe Contact
Bo Sorensen
SSH Communications Security Corp.
Tel: +358 20 500 7404
E-mail:

Investor Relations
Mika Peuranen
SSH Communications Security Corp.
Tel: +358 20 500 7419
E-mail:

U.S. Agency Contact
Cheryl Seaberg
Walt & Company
Tel: +1 408 496 0900 x 2981
E-mail:

Asia Pacific Contact
Shiho Hashimoto
SSH Communications Security Corp.
Tel: +358 20 500 7470
E-mail:

© 2002 SSH Communications Security Corp. All rights reserved. ssh® is a registered trademark of SSH Communications Security Corp in the United States and in certain other jurisdictions. All other names and marks are property of their respective owners.