[ISN] CORE-SDI-04: SSH insertion attack (fwd)
Petr Nachtmann
petrnach at natur.cuni.cz
Wed Jun 17 12:45:30 CEST 1998
Zahrnuji soucasne klienty a servery pro SSH tu 'new revision'?
PN
---------- Forwarded message ----------
Date: Thu, 11 Jun 1998 23:36:35 -0600 (MDT)
From: mea culpa <jericho at dimensional.com>
To: InfoSec News <isn at sekurity.org>
Subject: [ISN] CORE-SDI-04: SSH insertion attack (fwd)
[I know a lot of you will have already seen this, but it is worth
forwarding considering how many people use ssh these days. - Nick]
-------------------------------------------------------------------------------
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
<futo at core-sdi.com> and Emiliano Kargieman <ek at core-sdi.com>
CORE SDI wishes to thank the SSH maintainers Tatu Ylonen <ylo at ssh.fi>
and Tero Kivinen <kivinen at ssh.fi> for their quick response to the
issues rised by this advisory.
Olli Voima <olli.voima at DataFellows.com> 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 <futo at core-sdi.com>
Emiliano Kargieman <ek at core-sdi.com>
For more information about CORE SDI S.A. contact <core at core-sdi.com>
or visit <http://www.core-sdi.com>
You can contact CORE SDI S.A. at <corelabs at core-sdi.com> using the
the following PGP key:
Type Bits/KeyID Date User ID
pub 1024/CF4E0CF5 1998/05/18 CORELABS <corelabs at core-sdi.com>
-----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 Seguridad de la Informacion S.A. ]=======
Ivan Arce
Gerencia de Tecnologia Email : ivan at core-sdi.com
Av. Santa Fe 2861 5to C TE : +54-1-821-1030
CP 1425 FAX : +54-1-821-1030
Buenos Aires, Argentina Mensajeria: +54-1-317-4157
==============================================================================
-o-
Subscribe: mail majordomo at sekurity.org with "subscribe isn".
Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
More information about the Smajlik
mailing list