ssh-insertion-attack.txt

`-------------------------------------------------------------------------------  
  
  
CORE SDI S.A.  
Buenos Aires, Argentina  
<http://www.core-sdi.com>  
  
  
Security Advisory  
June 11th, 1998   
  
SSH insertion attack  
  
-------------------------------------------------------------------------------  
  
  
This advisory addresses a vulnerability present in the SSH software  
package that allows an attacker to execute arbitrary commands on the   
SSH server or otherwise subvert an encrypted SSH channel with  
arbitrary data.  
  
Problem Description  
~~~~~~~~~~~~~~~~~~~  
  
SSH (Secure Shell) is a program that provides strong authentication and   
secure communications over insecure channels.  
Its widely used for logging in to remote computers, file transfers and  
tunneling of other protocols over the encrypted comunications channel.  
All communications are automatically and transparently encrypted.  
Encryption is also used for integrity checking purposes although   
current implementations rely on a 32 bit Cyclic Redundancy Check  
to perform integrity checks after the decryption of an incoming packet.  
  
Encryption is done using one of a list of supported algorithms that  
is exchanged between client and server.  
Upon conection establishment client and server perform a protocol  
negotiation that includes mutual authentication, selection  
of a cipher supported by both ends for subsequent communications and  
of a session key to be used with the cipher. Encryption is then  
turned on using the selected cipher and session key, all further   
communications are encrypted.  
  
Currently supported ciphers are:  
  
- Blowfish  
Bruce Schneier's block cipher using a 128 bit key   
- IDEA  
A 128 bit block cipher   
- DES  
The Data Encryption Standard 56-bit block cipher  
- Triple DES (3DES)  
A three-key triple-DES algorithm with an effective key lenght  
of 112 bits.  
- ARCFOUR  
An RC4 compatible stream cipher using a 128 bit key  
  
The use of these algorithms in CBC (Cipher Block Chaining) or  
CFB (Cipher Feedback 64 bits) modes with the CRC-32 integrity check  
allows to perform a known plaintext attack (with as few as  
16 bytes of known plaintext) that permits the insertion of encrypted  
packets with any choosen plaintext in the client to server stream  
that will subvert the integrity checks on the server and decrypt to  
the given plaintext, thus allowing an attacker to execute arbitrary  
commands on the server.  
The attack is equally feasible on the server to client stream ,  
although it just gives the ability to send arbitrary data the  
user's terminal. The implications of such an attack are probably not  
as severe as an attack to the server side of the connection but  
must be taken in consideration in the process of applying fixes.  
  
Technical details  
~~~~~~~~~~~~~~~~  
  
After the protocol identification phase, where the server  
sends a plaintext string specifiying its the protocol and software   
versions, all communication is done encapsulating data in a  
packet format described as 'The Binary Packet Protocol' [1]  
The packet layout is as follows:  
  
32 24 16 8 0  
+----------+---------+---------+---------+  
| data length (bytes) |  
+----------+---------+---------+---------+  
| 1 to 8 bytes of padding |  
= =  
+----------+---------+---------+---------+  
| type | |  
+----------+ +  
| |  
= data =  
| |  
+----------+---------+---------+---------+  
| CRC-32 |  
+----------+---------+---------+---------+  
  
  
Data length: Length in bytes of the given packet, not including   
the length field and padding   
Padding : 8 - (length mod 8) bytes of random data, putting  
random data at the beginning of the packet is an   
effort to make known plaintext attacks more difficult.  
Packet type: An 8-bit unsigned byte.  
Data : length - 5 data bytes  
CRC-32 : the four 8-bit check bytes, MSB first. The CRC is  
computed before any encryption  
  
Encryption is done on the padding+type+data+CRC fields, the length  
field is never encrypted. The encrypted portion of the packet has  
a length that is always a multiple of 8 bytes.  
  
Knowning certain characteristics of the cipher modes being used,  
i.e. CBC, with a known plaintext an attacker is able to build a  
custom SSH packet (i.e. a type SSH_CMSG_STDIN_DATA packet) with  
the padding bytes computed in a way such that the next 8-bytes  
of the encrypted data will decrypt to arbitrary plaintext. In  
this particular case, the decrypted data will correspond to the  
type field and 7 data bytes.   
After the 16 bytes (padding+type+7 data bytes) the attacker would  
include a variable length of data bytes specifically crafted to  
produce a valid CRC-32 field for the whole packet once it is  
decrypted.  
This attack and several variations using the same technique can  
be performed due to the usage of weak integrity check schemes, in  
particular CRC-32 has certain properties that allows the attacker  
to forge a valid CRC for her corrupted packet.  
  
However, for the attack to succeed the attacker must be able to  
perform an active network attack, by either intercepting the  
legit SSH connection at any point between the client and server and  
injecting a forged packet or by performing a TCP session hijack attack.  
Such an attack is described in [6] and for SSH the two methods of  
TCP desynchronization can be used. In particular the method described  
as "Null data desynchronization" can be carried out using packets of  
type SSH_CMSG_IGNORE.  
  
Note that the new revision for the SSH protocol, proposed and  
published as Internet Drafts [2],[3],[4] [5] makes use of  
cryptographycally strong message authentication codes for  
integrity checks that wont fail to these attacks.   
  
Its is important to mention that despise the vulnerabilities  
found in the SSH protocol, it still remains to be a much more  
secure alternative to telnet, rsh and rlogin applications.  
  
  
[1] "The SSH (Secure Shell) Remote Login Protocol", T. Ylonen  
Helsinki University of Technology. November 15th 1995  
(draft expired on May 15th, 1996)  
  
Included as the file ./RFC in the ssh distribution  
<http://www.cs.hut.fi/ssh>  
  
[2] "SSH Protocol Architecture", draft-ietf-secsh-architecture-01.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
[3] "SSH Connection Protocol", draft-ietf-secsh-connect-03.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
[4] "SSH Authentication Protocol", draft-ietf-secsh-userauth-03.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
[5] "SSH Transport Layer Protocol",draft-ietf-secsh-transport-03.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
(drafts expired on May 7th, 1998)  
  
All Internet drafts are available at <ftp://ftp.isi.edu/internet-drafts/>  
  
[6] "Simple Active Attack Against TCP", Laurent Joncheray,   
Merit Networks Inc., 5th USENIX Security Simposium. 1995.  
  
  
Impact:  
~~~~~~  
An attacker with access to the encrypted SSH stream may insert  
encrypted blocks in the stream that will decrypt to   
arbitrary commands to be executed on the SSH server.  
  
Fix Information:  
~~~~~~~~~~~~~~~  
  
Upgrade to the upcoming SSH protocol version 2.  
  
Commercial F-Secure SSH users contact Data Fellows Inc. for  
information on how to upgrade to F-Secure 2.0  
  
Notice that version 2 of the SSH protocol is not   
compatible with the previous version, thus you  
will need to upgrade all the SSH clients as well.  
  
In the meantime, upgrade to version 1.2.25 of SSH, which  
fixes the problem. The SSH 1.2.25 distribution can be   
obtained from:  
  
<ftp://ftp.cs.hut.fi/pub/ssh/ssh-1.2.25.tar.gz>  
  
F-Secure SSH version 1.3.5 fixes this security problem.  
If you are using the commercial Data Fellows SSH package and you  
have a support contract, you can obtain the 1.3.5 from your local  
retailer.  
  
Users without a support contract can obtain a patch which fixes   
this problem from:  
  
<http://www.DataFellows.com/f-secure/support/ssh/bug/su134patch.html>.  
  
A patch for the free SSH 1.2.23 distribution and the complete  
SSH 1.2.23 package, with the patch applied, can be obtained at:  
  
<http://www.core-sdi.com/ssh>  
  
Below are the MD5 hashes for the provided files  
  
MD5 (ssh-1.2.23.patch) = 6bdb63d57f893907191986c5ced557ab  
MD5 (ssh-1.2.23-core.tar.Z) = fffb52122aae26c1f212c051a305a310  
MD5 (ssh-1.2.23-core.tar.gz) = f9509ba0f0715637805c6b116adc0869  
  
  
Vulnerable Systems:  
~~~~~~~~~~~~~~~~~  
  
All systems running implementations of SSH using protocol version 1.x  
are vulnerable.  
This includes SSH software versions up to 1.2.23 and F-Secure SSH 1.3.4  
  
To obtain the version of the SSH server that is running  
on a given host you can issue the following commands:  
  
  
$ telnet <IP address> 22  
Trying <IPaddress>...  
Connected to <IPaddress>.  
Escape character is '^]'.  
SSH-1.5-1.2.23  
\ / \--------- software version  
|------------ protocol version  
  
^]  
telnet> close  
Connection closed.  
$ exit  
  
  
Additional Information:  
~~~~~~~~~~~~~~~~~~~~~~  
  
These vulnerabilities were discovered by Ariel Futoransky  
<[email protected]> and Emiliano Kargieman <[email protected]>  
  
CORE SDI wishes to thank the SSH maintainers Tatu Ylonen <[email protected]>  
and Tero Kivinen <[email protected]> for their quick response to the  
issues rised by this advisory.  
  
Olli Voima <[email protected]> of Data Fellows Inc.   
provided the fix information for the F-Secure products.  
  
Comments and questions regarding this advisory should be sent to:  
  
Ariel Futoransky <[email protected]>   
Emiliano Kargieman <[email protected]>  
  
For more information about CORE SDI S.A. contact <[email protected]>  
or visit <http://www.core-sdi.com>  
  
You can contact CORE SDI S.A. at <[email protected]> using the  
the following PGP key:  
  
Type Bits/KeyID Date User ID  
pub 1024/CF4E0CF5 1998/05/18 CORELABS <[email protected]>  
  
-----BEGIN PGP PUBLIC KEY BLOCK-----  
Version: 2.6.3ia  
Comment: Requires PGP version 2.6 or later.  
  
mQCNAzVgfMgAAAEEAJSfJNdvCwIAc4AK0ckeimubLIwzsRVDRhjPQIOYt/7kxxio  
DZybr53fwMEjyT8cHXRL08i0R9rcuFeCNAez6XcalbhqUKXDcLL/cZK80CCDSCs5  
tRCZGGOEBnXQIoyvbvi4gNYhBS5wUvmh3b/mvRFTvhmRrUy9m/nO/LnPTgz1AAUR  
tCBDT1JFTEFCUyA8Y29yZWxhYnNAY29yZS1zZGkuY29tPokAlQMFEDVgfMn5zvy5  
z04M9QEBC6ED/0Szt3f54JTvkZG3ezQ8G60HvAw4/A5Ti6i3oze6jsXxzGp6pA1x  
i0jaZpKaUSpo0MLc7BcijMKneuUHnN3XtN5YxtFt0aEoot1MIvv4BsdeUb3x257G  
3+vr8SxGk44Vm4tfuN8F/2dNo/00yYP9rd3zQ8Tl+gmr5VxnLViZIDuh  
=ulRg  
-----END PGP PUBLIC KEY BLOCK-----  
  
Copyright Notice:  
~~~~~~~~~~~~~~~~  
The contents of this advisory are Copyright (C) 1998 CORE SDI S.A.,  
and may be distributed freely provided that no fee is charged for  
this distribution, and proper credit is given.  
  
  
$Id: ssh-advisory.txt,v 1.8 1998/06/11 22:05:03 iarce Exp $  
  
-------------------------------------------------------------------------------  
  
  
CORE SDI S.A.  
Buenos Aires, Argentina  
<http://www.core-sdi.com>  
  
  
General Description  
July 3rd, 1998  
  
SSH insertion attack   
  
--------------------------------------------------------------------------------  
  
  
Crc32 Compensation attack against ssh-1.5  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
  
This file gives a general description of the construction of a crc compensation  
attack against SSH protocol version 1.5. More information on the scope and   
characteristics of this attack, and the original advisory is available at   
<http://www.core-sdi.com/ssh>  
  
The attacker is assumed to have active access to the network where the  
cipherstream travels. She doesnt know neither the private server keys,  
nor the simetric session key.  
The server is trusted, it wont reveal private information and wont give  
any direct access to the attacker.   
These attacks works for any authentication method used because they are  
done after the authentication phase of the protocol negotiation.  
  
  
1. Feedback modes  
~~~~~~~~~~~~~~~~~  
  
SSH is currently using two different feedback modes for its block ciphers:   
Cipher FeedBack (CFB) and Cipher Block Chaining (CBC).  
The feedback is applied in the same way in every cipher algorithm  
SSH uses.  
An Initialization Vector is not negotiated in the SSH protocol and an  
IV of all zeros is used.  
  
Cipher block chaining is:  
  
Ci = Ek ( Pi xor Ci-1 )  
Pi = Dk ( Ci ) xor Ci-1  
  
CFB-64 is:  
  
Ci = Ek ( Ci-1) xor Pi  
Pi = Ek ( Ci-1) xor Ci  
  
Ci = ith block of the cipher stream.  
Pi = ith block of the plain stream.  
Ek(x) = Encryption of block x using k as key.  
Dk(x) = Decryption of block x using k as key.  
C0 = IV  
  
  
The use of the feedback strengthens the way the block cipher is used randomizing  
its input and reducing the information an eavesdropper can get from  
repeated plaintext blocks.   
However, using this feedback modes doesnt protect the protocol against  
replay-attacks or cut-and-paste. If the blocks C1..Cj are inserted in  
cipher stream, block C1 will be decrypted to garbage, and blocks C2..Cj  
will be decrypted to P2..Pj.  
  
If an active eavesdropper knows some block of the plaintext stream, he  
may insert any block using the ciphertext stream.   
The attacker knows the ciphertext stream C1..Cj and she knows also that Ci   
will decrypt to a particular Pi due to protocol characteristics. Now, since  
the attacker has the Ci/Pi known-plaintext pair and assuming that X is any  
arbitrary block the attacker may choose, she may insert the following blocks:   
  
  
CBC:  
===  
Cj+1 = X  
Cj+2 = Ci  
  
And will be decrypted to  
Pj+1 = Cj Xor Dk(X) = ?  
Pj+2 = X Xor Dk(Ci) = X Xor Ci-1 Xor Pi  
  
CFB:  
===  
Cj+1 = Ci-1  
Cj+2 = X  
  
And will be decrypted to  
Pj+1 = Ci-1 Xor Ek(Cj) = ?  
Pj+2 = X Xor Ek(C-1) = X Xor Pi Xor Ci  
  
The attacker cant control whats in Pj+1, but she can insert any block at  
Pj+2 because she controls X.  
  
It should be considered also that for CBC modes, the IV is plain XORed  
to the first block, although the IV is always zero and cannot be  
modified. For CFB-64, the last block is plain XORred to the encription of  
its previous block and can be modified in an easy manner.  
  
  
2. Checksum  
~~~~~~~~~~~  
SSH-1.5 protocol includes a checksum field within each packet that  
incorporates redundancy that allows the receiver of the packet to verify  
the integrity and authenticity of the packet with a defined threshold of  
2^-32.  
CRC32, the integrity function, is a linear function in Z2-spaces, the   
remainder from the division of the input stream (as a polinomy in Z2)  
with the constant polinomy:   
  
(X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0)  
  
As a result of this definition, the following propierties hold:  
  
Crc32(A Xor B) = Crc32(A) Xor Crc32(B)  
Crc32('0' + A) = Crc32(A)  
If Crc32(A) = 0 Then Crc32(A + '0') = 0  
  
( '+' in this context means concatenate. '0' means one 0 Bit)  
  
  
3. Packet  
~~~~~~~~~  
SSH-1.5 defines the following packet format:  
  
32 24 16 8 0  
+----------+---------+---------+---------+  
| data length (bytes) |  
+----------+---------+---------+---------+  
| 1 to 8 bytes of padding |  
= =  
+----------+---------+---------+---------+  
| type | |  
+----------+ +  
| |  
= data =  
| |  
+----------+---------+---------+---------+  
| CRC-32 |  
+----------+---------+---------+---------+  
  
Datalen is unencrypted, the rest is encrypted with the selected  
blockcipher and feedback mode. The last block of the previous packet is  
used in the feedback. The padding is added to make the packet size be a  
multiple of 64-bits, and to include at least one padding byte. The crc32  
is applied to padding, type and data.  
  
Within a packet, there are two message types that are of particular interest   
and could be directly used in an attack: SSH_STDIN_DATA and SSH_STDOUT_DATA, as   
defined in [1]. These type of messages has the following message structure:  
  
+-------+------------------------+---------------------------------------------+  
| TYPE | 32-Bit Message Length | Message data |  
+-------+------------------------+---------------------------------------------+  
  
SSH closes the connection if:  
A) The crc-32 field is not consistent with the packet  
pad/type/data.  
B) The 32-bit message len is not equal to the packet len minus  
fields.  
C) The message type is invalid  
  
Within a single cipher block fits:  
+ 1 Byte type field  
+ 4 Bytes Message length  
+ 3 Bytes data  
  
  
4. ATTACK  
~~~~~~~~~  
A)  
  
The last block of the packet looks like:  
  
+---------+--------+--------+--------+----------+---------+---------+---------+  
| LAST 4 BYTES | CRC-32 |  
+---------+--------+--------+--------+----------+---------+---------+---------+  
  
If CFB-64 is used, the last ciphered block Cj, is not encrypted using  
the blockcipher but is plain XORed to Ek(Cj-1).  
Given that Crc(A XOR B) = Crc(A) XOR Crc(B), an attacker may replace the  
last block of the packet in the cipherstream with the XOR of the  
existing block and 8-bytes block with a valid crc.  
Because of the linear characteristics of crc32 the packet will have a  
valid crc.  
The last four bytes of the data field in a packet could be modified by  
an attacker in an easy way.  
  
If the attacker knows what is in the last four bytes of the data field, she   
may replace them with arbitrarily choosen bytes.  
  
B) If CBC mode is used, and an attacker have two Pi/Ci  
known-plaintext/ciphertext blocks she may follow the following steps  
creating a new valid packet that could be inserted in the stream  
regardless of the blockcipher and key used.   
The known plaintext/ciphertext pair is Pi/Ci, Pj, Cj  
The packet is at Cl..Cm and Pl..Pm.  
  
  
I. The attacker choose the packet length to be a multiple of 64-bits, so  
the padding will be 64-bits.  
  
II. She starts the packet with two cipher blocks:   
Cl = X  
Cl+1 = Ci  
  
X is choosen to make Pl+1 a block with a valid type and 7-bytes of  
selected data. Pl is unknown to the attacker, but its the padding field  
of the packet, and is not used in the protocol (except for the crc32  
computation).  
  
III. The attacker appends 32 64-bits blocks to the cipher stream  
Cl+3..Cl+34. Each block is either X (The same choosen in step II) or Ci  
in a particular combination that makes the final crc on Pl+3..Pl+34  
independent on the value of Dk(X). That is, for each possible value  
of Dk(X) the crc of those blocks is the same.   
This combination exists, and can be found, because of the  
characteristics of the crc function mentioned on point 2.  
  
IV. The attacker appends 32 64-bits blocks to the cipher stream Cl+35..Cl+67.  
Each block is either Ci (Known Ciphertext A) or Cj (known ciphertext B)  
making a particular pattern that fix the crc result to the value Pi XOR  
Ci (paying attention to the last two blocks appended in step V below).   
  
V. The attacker adds two Ci blocks to the cipherstream appending the  
crc32 field to the packet.  
Cm-1 = Ci  
Cm = Ci  
  
The final encrypted packet looks like:  
  
X [block] X/Ci X/Ci X/Ci .... Ci/Cj Ci/Cj Ci/Cj Ci/Cj ... Ci Ci   
  
Where 'block' is the constructed block with type/messagelen/data.  
  
C) If CFB-64 mode is used and an attacker has one Pi/Ci Known  
plaintext/ciphertext pair she may follow the following steps to  
construct a valid packet that will subvert the integrity mechanism.  
The known plaintext/ciphertext pair is Pi/Ci, 'I' is the last block of  
the previous packet.  
The new packet is to be inserted at Cl..Cm and Pl..Pm.  
  
I. The attacker chooses the packet length to be a multiple of 64-bits, so  
the padding will be 64-bits.  
  
II. Two blocks are appended to the cipher stream:  
  
Cl = Ci  
Cl+1 = X  
  
The attacker selects X to make Pl+1 a valid type and 7 data bytes block.  
Pl is unknown but is entirely contained in the padding field.  
  
III. The attacker inserts 32 64-bit blocks to the cipher stream. Each  
block is either 'I' or Ci defining a particular pattern that will make the  
final crc for the packet independent of Ek(I). This step is needed  
because in cfb-64 what is feeded into to the new packet is Ek(I), as   
oppossed to CBC mode where 'I' unencripted is feeded.  
  
IV. The attacker appends 32 64-bit blocks to the cipher stream. Each  
block is either Ci or X in a particular combination that defines a  
pattern for which the CRC on the decrypted stream does not  
depend on the value of Dk(X).   
This is the same process used in Step III of attack B.  
  
V. The attacker adds two blocks to end the cipher stream: Ci and Y.  
Ci is the ciphertext of the known plain/ciphertext.   
Y is the last block of the cipherstream for that packet, it's directly  
XORed to Ek(Ci). She must select Y to make the crc32 field consistent  
with the constructed packet. The crc of the packet could be calculated  
because it doesnt depend on the unknown Ek(X) value nor on Ek(I).  
  
The final packet (encrypted) looks like:  
  
Ci X Ci/I Ci/I Ci/I .... Ci/X Ci/X Ci/X .......... Ci Y  
  
  
5. FINAL CONSIDERATIONS   
~~~~~~~~~~~~~~~~~~~~~~~  
The last two described attacks B, C, defined attacks that inserts 1  
selected block of 8 bytes with arbitrary choosen data thru the cipher  
stream that decrypts to a valid type/messagelen/data with 3 bytes of  
data that will be inserted into the input stream of the running program or  
into the client terminal. More that 3 bytes could be inserted  
by appending more than one Ci, X (X, Ci for CBC) pair at the beginning  
of the packet, and compensating it's crc later. Most shells include special  
meta-characters that could help the attacker deal with 8 unknown  
characters between each 8-bytes choosen blocks (i.e. ` or ').  
  
The calculation of the X/Ci pattern that doesnt depend on Dk(X) and the  
calculation of Ci/Cj for a particular crc can be done easily and  
efficiently with basic linear algebra. This doesnt imply 2^32  
calculations, although 2^32 is within the power reach of most  
microcomputers.  
  
The known plaintext/ciphertext pair could easily be found on  
ssh-protocol stream given that the attacker knows something about the  
terminal type or the destination system that the client is trying to  
connect to. SSH includes this kind of information at fixed positions on  
particular messages exchanged during the initial negotiation that could be   
identified by its size (the packet length is sent unencrypted on the network   
stream).  
Other sources of known-plaintext are for example the /etc/motd that is  
displayed at logon on most unixes. 16 and 8 bytes of known plaintext is  
enough for attacks B and C respectively.  
  
Attack A is less practical than B and C because the known plaintext  
block must be fixed at a particular place within the packet, and it  
cannot be extended for more than 4 bytes. However attack A needs no  
known plaintext at all.  
  
The attacker needs active access to the network stream of the ssh  
protocol. That means that she must have access to one machine that's  
connected to any segment on the connection's path and has  
sniffing/spoofing capabilities on the network.  
  
  
6. REFERENCES  
~~~~~~~~~~~~~  
  
[1] "The SSH (Secure Shell) Remote Login Protocol", T. Ylonen  
Helsinki University of Technology. November 15th 1995  
(draft expired on May 15th, 1996)  
  
Included as the file ./RFC in the ssh distribution  
<http://www.cs.hut.fi/ssh>  
  
[2] "SSH Protocol Architecture", draft-ietf-secsh-architecture-01.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
[3] "SSH Connection Protocol", draft-ietf-secsh-connect-03.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
[4] "SSH Authentication Protocol", draft-ietf-secsh-userauth-03.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
[5] "SSH Transport Layer Protocol",draft-ietf-secsh-transport-03.txt.gz  
T. Ylonen, T. Kivinen, M. Saarinen. SSH. November 7th, 1997   
  
(drafts expired on May 7th, 1998)  
  
All Internet drafts are available at <ftp://ftp.isi.edu/internet-drafts/>  
  
[6] "Simple Active Attack Against TCP", Laurent Joncheray,   
Merit Networks Inc., 5th USENIX Security Simposium. 1995.  
  
  
[7] "Problem areas for the IP Security Protocols", Steve Bellovin,  
USENIX 1996. <http://www.research.att.com/~smb/papers/badesp.ps>  
  
  
[8] "On Message Integrity in Cryptographic Protocols",  
S. Stubblebine and V. Gligor, IEEE Computer Society Symposium on  
Research in Security and Privacy, Oakland, CA, May, 1992, pp. 85-104.  
  
[9] "Protocol Design for Integrity Protection", S. Stubblebine and V. Gligor,  
IEEE Computer Society Symposium on Research in Security and Privacy,  
Oakland, CA, May, 1993, pp. 41-53.   
  
  
Additional Information:  
~~~~~~~~~~~~~~~~~~~~~~~  
  
These vulnerabilities were discovered by Ariel Futoransky  
<[email protected]> and Emiliano Kargieman <[email protected]>  
  
Comments and questions regarding this attack should be sent to:  
  
Ariel Futoransky <[email protected]>   
Emiliano Kargieman <[email protected]>  
  
For more information about CORE SDI S.A. contact <[email protected]>  
or visit <http://www.core-sdi.com>  
  
You can contact CORE SDI S.A. at <[email protected]> using the  
the following PGP key:  
  
Type Bits/KeyID Date User ID  
pub 1024/CF4E0CF5 1998/05/18 CORELABS <[email protected]>  
  
-----BEGIN PGP PUBLIC KEY BLOCK-----  
Version: 2.6.3ia  
Comment: Requires PGP version 2.6 or later.  
  
mQCNAzVgfMgAAAEEAJSfJNdvCwIAc4AK0ckeimubLIwzsRVDRhjPQIOYt/7kxxio  
DZybr53fwMEjyT8cHXRL08i0R9rcuFeCNAez6XcalbhqUKXDcLL/cZK80CCDSCs5  
tRCZGGOEBnXQIoyvbvi4gNYhBS5wUvmh3b/mvRFTvhmRrUy9m/nO/LnPTgz1AAUR  
tCBDT1JFTEFCUyA8Y29yZWxhYnNAY29yZS1zZGkuY29tPokAlQMFEDVgfMn5zvy5  
z04M9QEBC6ED/0Szt3f54JTvkZG3ezQ8G60HvAw4/A5Ti6i3oze6jsXxzGp6pA1x  
i0jaZpKaUSpo0MLc7BcijMKneuUHnN3XtN5YxtFt0aEoot1MIvv4BsdeUb3x257G  
3+vr8SxGk44Vm4tfuN8F/2dNo/00yYP9rd3zQ8Tl+gmr5VxnLViZIDuh  
=ulRg  
-----END PGP PUBLIC KEY BLOCK-----  
  
Copyright Notice:  
~~~~~~~~~~~~~~~~~  
The contents of this document are Copyright (C) 1998 CORE SDI S.A.,  
and may be distributed freely provided that no fee is charged for  
this distribution, and proper credit is given.  
  
  
$Id: attack.txt,v 1.2 1998/07/03 21:22:27 iarce Exp $  
  
  
============================================================================  
  
CORE SDI S.A.  
Buenos Aires, Argentina  
<http://www.core-sdi.com>  
  
  
SSH insertion attack detection  
============================================================================  
  
  
Crc32 Compensation attack detector  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
This document describes the scope and characteristics of SSH crc32   
compensation attack detector engine. It will inspect an encrypted SSH protocol  
1.5 stream for suspicious patterns. If either the server or client is under  
attack, the detector closes the conection and logs the attack.  
  
  
Attack characteristics  
~~~~~~~~~~~~~~~~~~~~~  
An attacker, with sniffing and spoofing capabilities on the SSH network stream, may perform an active network attack by constructing a packet using a   
known cipher/plaintext pair and computing addditional data to fill the packet  
in a way that will produce a valid CRC-32 field and pass as a valid packet when  
decryped and integrity checked on the server side.  
If the attack succeeds, arbitrary commands will get executed on the server.  
  
This attack doesnt affect the confidential security characteristics of the  
products using this protocols. However, integrity and authentication   
of packets can no longer be trusted.  
  
Solution  
~~~~~~~  
This is not an implementation bug, but a protocol design vulnerability. The  
protocol must be updated to use cryptographic strong message authentication  
codes. SSH Protocol version 2 as published in [1] includes the use of a real  
strong MAC.  
However, this will require to update all clients and servers simultaneusly  
while disabling compatibility with protocol version 1.5. On many installations  
this is not practical.  
  
A mid-term solution exists, that will help protecting the server from the  
auth/integrity vulnerabilities. On most scenarios it will be enough to upgrade  
only the servers.   
  
This approach is based on the fact that an attacker will need to exploit some  
of the linear characteristics of the integrity function in order to implement  
the attack. In that context, the constructed packets will follow certain   
patterns that could be detected on the encrypted stream.  
  
This is not a general solution, but a countermeasure against a model of all  
of the possible attacks that exploits this vulnerabilities.   
  
The provided patch looks for patterns of repeated ciphered blocks in  
each SSH packet received, the performance loss in speed is less 2% in an  
uncompressed stream compared to an unpatched server. Memory usage increases   
in about 8k per conection.  
The chances of reporting a false attack in a 32GB file transfer is around  
1 in 2**51.  
  
Contact information  
~~~~~~~~~~~~~~~~~~  
  
These vulnerabilities were discovered by Ariel Futoransky  
and Emiliano Kargieman.  
  
Comments and questions regarding this vulnerability and the fix  
should be sent to:  
  
Ariel Futoransky <[email protected]>  
Emiliano Kargieman <[email protected]>  
  
For more information about CORE SDI S.A. contact <[email protected]>  
or visit <http://www.core-sdi.com>  
  
For more information about this problem and related ones visit:  
  
<http://www.core-sdi.com/ssh>  
  
You can contact CORE SDI S.A. at <[email protected]> using the  
the following PGP key:  
  
-----BEGIN PGP PUBLIC KEY BLOCK-----  
Version: 2.6.3ia  
Comment: Requires PGP version 2.6 or later.  
  
mQCNAzVgfMgAAAEEAJSfJNdvCwIAc4AK0ckeimubLIwzsRVDRhjPQIOYt/7kxxio  
DZybr53fwMEjyT8cHXRL08i0R9rcuFeCNAez6XcalbhqUKXDcLL/cZK80CCDSCs5  
tRCZGGOEBnXQIoyvbvi4gNYhBS5wUvmh3b/mvRFTvhmRrUy9m/nO/LnPTgz1AAUR  
tCBDT1JFTEFCUyA8Y29yZWxhYnNAY29yZS1zZGkuY29tPokAlQMFEDVgfMn5zvy5  
z04M9QEBC6ED/0Szt3f54JTvkZG3ezQ8G60HvAw4/A5Ti6i3oze6jsXxzGp6pA1x  
i0jaZpKaUSpo0MLc7BcijMKneuUHnN3XtN5YxtFt0aEoot1MIvv4BsdeUb3x257G  
3+vr8SxGk44Vm4tfuN8F/2dNo/00yYP9rd3zQ8Tl+gmr5VxnLViZIDuh  
=ulRg  
-----END PGP PUBLIC KEY BLOCK-----  
  
Copyright  
~~~~~~~~  
  
This file, deattack.c and deattack.h are copyright (c) 1998  
CORE SDI S.A., Buenos Aires, Argentina. All rights reserved.  
and should be redistributed or modified for non-commercial purposes only  
provided that this copyright notice is retained.  
  
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES  
ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY DIRECT,  
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES RESULTING  
FROM THE USE OR MISUSE OF THIS SOFTWARE.  
  
  
`