SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Security)  >   SSH Vendors:   SSH Communications
SSH.com's Secure Shell (SSH) Implementation Weakness May Disclose User Keys to Remote Users During Man-in-the-Middle Attacks
SecurityTracker Alert ID:  1004817
SecurityTracker URL:  http://securitytracker.com/id/1004817
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jul 23 2002
Impact:   Disclosure of authentication information, User access via network
Exploit Included:  Yes  

Description:   A vulnerability was reported in the SSH1/SSH2 interoperability code in several secure shell (SSH) implementations. A remote user that can conduct a 'man-in-the-middle' attack may be able to obtain a user's login username and password.

The implementation weakness can reportedly allow a 'man-in-the-middle' attack to cause an affected SSH client to determine that there is no hostkey for communicating with the destination server when in fact the hostkey is already in the client's list of known keys. This may occur under a very specific (but potentially common) set of circumstances.

When receiving a server-supplied banner such as 'SSH-1.99-OpenSSH_2.2.0p1', the SSH client will reportedly choose either SSH protocol version 1 or SSH protocol version 2, depending on how the system is configured. If the system is configured in a manner that does not require one protocol version or the other to be used, and if the system contains the 'Protocol 1,2' configuration line, the client will select SSH protocol version 1. If this is the case, it may be likely that the particular SSH client has never used SSH protocol version 2 to communicate with the specified destination SSH server.

A remote user that can modify the intended destination server's banner can send a bogus banner to the client (such as 'SSH-2.00-TESO-SSH'). In response, the client will search in its known hostkey list and will not find the SSH2 key (if it has never communicated with that host using SSH2). Because the SSH2 key is not present (but the SSH1 key is), the client will not provide the usual warning banner. Instead, the client will request that the user accept the new key. Upon accepting the new key from the remote user's 'man-in-the-middle' software, the client software will generally send the login username and password to the remote user.

This attack can also reportedly be used in a protocol version downgrade manner (going from SSH2 to SSH1), as well.

Also, a similar attack using RSA and DSA keys is reportedly possible.

For more information, see the original report at:

http://segfault.net/~stealth/ssharp.pdf

Impact:   A remote user may be able to conduct a man-in-the-middle attack to obtain the client user's login username and password.
Solution:   No solution was available at the time of this entry.
Vendor URL:  www.ssh.com/ (Links to External Site)
Cause:   State error
Underlying OS:  Linux (Any), UNIX (Any), Windows (Any)

Message History:   None.


 Source Message Contents

Subject:  Re: SSH Protocol Trick


On Tue, Jul 23, 2002 at 04:50:22PM +0200, Martin Peikert wrote:

Hi,

Because I have been asked for the .pdf several times,
the .pdf paper can be found aT

 http://segfault.net/~stealth/ssharp.pdf

Its more or less the same as in phrack59 but also contains some
screenshots of a ssharp session. Paper plus program will be uploaded
to 7350.org as soon as the issue has been "solved" by SSH vendors
and some corrections made it into the text.

regards,
S.

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2020, SecurityGlobal.net LLC