Vulnerability Note VU#565052
Passwords sent via SSH encrypted with RC4 can be easily cracked
Passwords sent using SSH with RC4 encryption can be easily cracked by an attacker who is able to capture and replay the session. This problem occurs for three reasons: SSH sessions can be replayed, the RC4 encryption algorithm has some specific weaknesses, and the SSH daemon provides too much information during the authentication phase of the protocol.
The SSH daemon has an option that will disallow NULL passwords. While enabling this option usually results in improved security (by preventing NULL passwords), it can be used under certain conditions to crack passwords as well.
An attacker launches such an attack with the following steps:
- Capture (by sniffing) a legitimate session between the client and the server using RC4 encryption. The only packets needed are those up to and including where the password is sent.
- Because of vulnerability VU#665372, the captured session can be replayed to the server for one hour. The attacker replays the captured session until the password packet is about to be sent.
- The attacker guesses the first character of the password and modifies the password packet by XORing this guessed character with the first character of the password in the packet. The CRC of the modified packet must be re-computed.
- When the modified packet is received by the server and decrypted, if the guess was correct the resulting first character of the password will be NULL. This is because the RC4 encryption algorithm is a stream cipher in which a sequence of random bits are XORed with the plaintext to produce the cipher text. Two identical characters XORed together produce zero, and the random bits in the RC4 stream do not need to be known since the server will correctly "decrypt" this byte.
- If the server is configured to reject NULL passwords, and the guess was correct, the server will generate a debugging message indicating that null passwords are not allowed. The attacker now knows the first character of the password. If the guess was incorrect, the server generates a different message, and the attacker goes back to step two and guesses a different character.
- Once the attacker knows the first character of the password, they can repeat this process to obtain other characters of the password. They simply need to make some additional changes to the SSH password packet. An SSH password packet (SSH_CMSG_AUTH_PASSWORD) has the following structure:
Packet length (4 bytes, not encrypted)
Padding (X bytes, encrypted)
Packet Type (1 byte, encrypted)
String Length (4 bytes, encrypted)
String Value (length bytes, encrypted)
CRC checksum (4 bytes, encrypted)
- To attack the next character of the password, the attacker reduces the packet length by one byte, which is easy since the packet length is not encrypted. This change causes the byte which was previously the packet type to become part of the packet padding, the first byte of the string length to become the packet type, the next three bytes of the string length and the first character of the string value to become the new string length, and so on. The interpretation of each of these bytes is shifted by one when the packet length changes.
- The attacker sets the new packet type to the correct type, the new string length to one less than before, and then guess the second character of the password as they did in step three. While this is somewhat more complicated than guessing the first character, it is trivial to compute these values since the same properties of the RC4 algorithm which allowed the first the attacker to guess the first character of the password can be applied to setting the packet type and string length. Specifically, the attacker knows the plaintext of the type field and can easily guess the value of the length field, revealing the "key bytes" of the RC4 stream. Once these bytes are known, new values can be generated. As before, the CRC at the end of the packet must be recomputed.
- This process can be repeated, decreasing the packet length and string length by one until the packet padding is eight bytes long. In practice this means that passwords less than seven characters in length can be recovered completely. But for seven character passwords, only the first character can be recovered, and for eight character passwords, only the first two characters can be recovered.
In another variation of the attack, if the attacker has an account on the same server as the victim, the attacker can set their own password to one character, replay the session, and detect if the first character is correct. They then set their password to two characters in length and replay the session again, detecting the second character. This approach requires changes to the string length field each time, but is more dangerous because it can recover seven and eight character passwords completely.
In summary, this problem occurs because the RC4 sessions can be replayed within the hour, the RC4 encryption algorithm has some unique features, and because the server generates different messages based on different failure modes during authentication.
The password used during an SSH session encrypted with RC4 can be recovered by an attacker who is able to capture and replay the session.
Do not use RC4 encryption
Because this vulnerability relies on a feature of RC4 encryption, the attack can be prevented by using a different encryption algorithm.
If you are a vendor and your product is affected, let
|Vendor||Status||Date Notified||Date Updated|
|SSH Communications Security||Affected||-||06 Feb 2001|
|OpenSSH||Not Affected||-||06 Feb 2001|
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 Cory F Cohen.
18 Jan 2001
Date First Published:
18 Jan 2001
Date Last Updated:
25 Oct 2001
If you have feedback, comments, or additional information about this vulnerability, please send us email.