[NEWS] SSH Protocol Weakness Vulnerability (MITM)

From: support@securiteam.com
Date: 07/24/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Wed, 24 Jul 2002 09:15:08 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  SSH Protocol Weakness Vulnerability (MITM)
------------------------------------------------------------------------

SUMMARY

A weakness in the backward compatibility of the SSH Protocol has been
found that will allow for a Men in the Middle attack. This is due to the
fact that a host having the host key for a certain protocol (let us say
SSH version 1.0) is unlikely to have the host key for the other protocol
(let us say SSH version 2.0). This would allow an attacker to pose as a
host by providing his own host key for encryption handling that is
preformed between the client and the server.

DETAILS

The SSH daemons advertise one of two major versions, depending on what is
supported by the software /configuration files, for SSH protocol version
1, or 2. Compatibility mode is enabled with a version of 1.99. Any server
that advertises the compatibility mode of 1.99 is vulnerable to the
attack. Servers in compatibility mode have both protocols 1 and 2 enabled.
If the client has a key enabled for say, only SSH protocol 1 or 2, the
malicious interloper, "Mallory", using SSH MITM ARP techniques that in
such products as, Ettercap or DSniff, can advertise the opposite protocol
in the fake SSHd version string used in the banner handshake. If a client
has only used say, SSH 1 authentication in the past, it will not contain a
SSH2 key, so no "Host Identification has changed" message will be present
when the fake server advertises its public host key. The targeted victim
will only see a "KEY NOT PRESENT" prompt and will be asked if they want to
add the key.

Obviously, this removes some of the fear paranoid users would feel when
facing a real MITM attack. Remember, this is not a direct vulnerability in
the SSH 1 or 2 protocols, but rather a slight trick that can be abused.

Potential solution:
Check known_hosts and known_hosts2 in your ~/.ssh directory, and check to
see which keys you use for each host. If you only use ssh1, force the SSH
protocol to protocol 1, by specifying the -1 option. Alternatively, if you
use SSH2, force the SSH protocol 2 with the -2 option. If you receive a
hostkey change identification, you know something must be up.

ADDITIONAL INFORMATION

The information has been provided by Robert.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages