==Phrack Inc.==

               Volume 0x0b, Issue 0x3b, Phile #0x0b of 0x12


|=-----------------=[ It cuts like a knife. SSHarp. ]=-------------------=|
|=-----------------------------------------------------------------------=|
|=----------------=[ stealth <[email protected]>  ]=------------------=|

--[ Contents

    - Intoduction

  1 - Playing with the banner

  2 - Playing with the keys

  3 - Countermeasures

  4 - An Implementation

  5 - Discussion

  6 - Acknowledgments

  7 - References


--[ Introduction

The Secure Shell (SSH) protocol which itself is considered strong is often
weakly implemented. Especially the SSH1/SSH2 interoperability as
implemented in most SSH clients suffers from certain weak points as
described below. Additionally the SSH2 protocol itself is also flexible
enough to contain some interesting parts for attackers.

For disclaimer see the pdf-version of this article available [here].

  The described mim-program will be made available one week after releasing
this article to give vendors time for fixes (which are rather trivial) to
limit the possibility of abuse.

  In this article I will describe how SSH clients can be tricked into
thinking they are missing the host-key for the host they connected to even
though they already have it in their list of known hosts. This is possible
due to some points in the SSH drafts which makes life of SSH developers
harder but which was ment to offer special protection or more flexibility.

  I assume you have a basic understanding of how SSH works. However it is
not necessary to understand it all in detail because the attacks succeeds
in the handshake where only a few packets have been exchanged. I also
assume you are familiar with the common attacking scenarios in networks
like Man in the Middle attacks, hijacking attacks against plaintext
protocols, replay attacks and so on.


--[ 1 - Playing with the banner

The SSH draft demands that both, client and server, exchange a banner
before negotiating the key used for encrypting the communication channel.
This is indeed needed for both sides to see which version of the protocol
they have to speak. A banner commonly looks like


  SSH-1.99-OpenSSH_2.2.0p1


A client obtaining such a banner reads this as "speak SSH1 or SSH2 to me".
This is due to the "1" after the dash, the so called remote major version.
It allows the client to choose SSH1 for key negotiation and further
encryption. However it is also possible for the client to continue with
SSH2 packets as the "99" tells him which is also called the remote minor
version. (It is a convention that a remote-minor version of 99 with a
remote-major version of 1 means both protocols.)

  Depending on the clients configuration files and command-line options he
decides to choose one of both protocols. Assuming the user does not force a
protocol with either of the "-1" or "-2" switch most clients should behave
the same way. This is due to the configuration files which do not differ
that much across the various SSH vendors and often contain the line


  Protocol 1,2


which makes the client choose SSH protocol version 1. It is obvious what
follows now. Since the SSH client used to use SSH1 to talk to the server it
is likely that he never spoke SSH2 before. This may be exploited by
attackers to prompt a banner like


  SSH-2.00-TESO-SSH


to the client. The client looks up his database of known hosts and misses
the host-key because it only finds the SSH1 key of the server which does
not help much because according to the banner he is not allowed to speak
SSH1 anymore (since the remote major version number is 2). Instead of
presenting a warning like


  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that the RSA1 host key has just been changed.
  The fingerprint for the RSA1 key sent by the remote host is
  f3:cd:d9:fa:c4:c8:b2:3b:68:c5:38:4e:d4:b1:42:4f.
  Please contact your system administrator.


if someone tries MiM attacks against it without the banner-hack, it asks
the user to just accept the new key:


  Enabling compatibility mode for protocol 2.0
  The authenticity of host 'lucifer (192.168.0.2)' can't be established.
  DSA key fingerprint is ab:8a:18:15:67:04:18:34:ec:c9:ee:9b:89:b0:da:e6.
  Are you sure you want to continue connecting (yes/no)?


It is much easier now for the user to type "yes" instead of editing the
known_hosts file and restarting the SSH client. Once accepted, the
attackers SSH server would record the login and password and would forward
the SSH connection so the user does not notice his account was just
compromised.

  The described attack is not just an upgrade attack. It also works to
downgrade SSH2 speaking clients to SSH1. If the banner would contain "2.0"
the client only spoke SSH2 to the original server and usually can not know
the SSH1 key of the server because he does not speak SSH1 at all. However
our MiM server speaks SSH1 and prompts the client once again with a key he
cannot know.

  This attack will not work for clients which just support one protocol
(likely to be SSH1) because they only implement one of them. These clients
should be very seldom and most if not all SSH clients support both
versions, indeed it is even a marketing-pusher to support both versions.

  If the client uses RSA authentication there is no way for the attacker to
get in between since he cannot use the RSA challenges presented to him by
the server because he is talking a different protocol to the client. In
other words, the attacker is never speaking the same version of the
protocol to both parties and thus cannot forward or intercept RSA
authentication.

  A sample MiM program (ssharp) which mounts the banner-hack and records
logins can be found at [ssharp].


--[ 2 - Playing with the keys

It would be nice to have a similar attack against SSH without a version
switch. This is because the version switch makes it impossible to break the
RSA authentication.

  Reading the SSH2 draft shows that SSH2 does not use the host-key for
encryption anymore (as with SSH1 where the host and server-key was sent to
the client which sent back the session-key encrypted with these keys).
Instead the client obtains the host-key to check whether any of the
exchanged packets have been tampered with by comparing the server sent MAC
(Message Authentication Code; the server computes a hash of the packets
exchanged and signs it using the negotiated algorithm) with his own
computed hash. The SSH2 draft is flexible enough to offer more than just
one static algorithm to allow MAC computation. Rather it specifies that
during key exchange the client and the server exchange a list of preferred
algorithms they use to ensure packet integrity. Commonly DSA and RSA are
used:


  stealth@liane:~> telnet 192.168.0.2 22
  Trying 192.168.0.2...
  Connected to 192.168.0.2.
  Escape character is '^]'.
  SSH-1.99-OpenSSH_2.2.0p1
  SSH-2.0-client
  `$es??%9?2?4D=?)??ydiffie-hellman-group1-sha1ssh-dss...


I deleted a lot of characters and replaced it with "..." because the
interesting part is the "ssh-dss" which denotes the servers favorite
algorithm used for MAC computation. Clients connecting to 192.168.0.2
cannot have a RSA key for computation because the server does not have one!
Of course the attackers MiM program has a RSA key and offers only RSA to
ensure integrity:


  stealth@liane:~> telnet 192.168.0.2 22
  Trying 192.168.0.2...
  Connected to 192.168.0.2.
  Escape character is '^]'.
  SSH-2.0-OpenSSH_2.9p1
  SSH-2.0-client
  at      s?eu??>vM??E=diffie-hellman-group-exchange-sha1,
  diffie-hellman-group1-sha1ssh-rsa...


A SSH client connecting to our MiM server will once again prompt the user
to accept the new key instead of issuing the MiM warning.

  The MiM server connected to the original server and got to know that he
is using DSA. He then decided to face the user with a RSA key. If the
original server offers DSA and RSA the MiM server will wait until the
client sends his preferred algorithms and will choose an algorithm the
client is naming for his second choice. A RFC compliant SSH2 server has to
choose the first algorithm he is supporting from the client list, our MiM
server will choose the next one and thus produces a key-miss on
client-side. This will again produce a yes/no prompt instead of the warning
message. "ssharp" also supports this key-hack mode.


--[ 3 - Countermeasures

Having the RSA host-key for a server offering a DSA host-key means nothing
for todays clients. They ignore the fact that they have a valid host-key
for that host but in a different key-type. SSH clients should also issue
the MiM warning if they find host-keys for the server where either the
version or type does not match. Its very likely someone in playing MiM
games. In my eyes it is definitely a bug in the SSH client software.


--[ 4 - An Implementation

There already exist some MiM implementations for SSH1 such as [dsniff] or
[ettercap]. Usually they understand the SSH protocol and put much effort
into packet assembling and reassembling or forwarding. Things are much
simpler.  ssharp is based on a normal OpenSSH daemon which was modified to
accept any login/password pair and starts a special shell for these
connections: a SSH client which is given the username/password and the real
destination IP. It logs into the remote host without user-interaction and
since it is bound to the mim servers pty it looks for the user like he
enters his normal shell. This way it is not needed to mess with SSH1 or
SSH2 protocol or to replace keys etc. We just play with the banner or the
signature algorithm negotiation the way described above.

  If compiled with USE_MSS option enabled, ssharp will slip the SSH client
through a screen-like session which allows attaching of third parties to
existing (mimed) SSH1 or SSH2 connections. It is also possible to kick out
the legitimate user and completely take control over the session.


--[ 5 - Discussion

I know I know; a lot of people will ask "thats all?" now. As with every
discovery plenty of folks will claim that this is "standard UNIX semantics"
or it is feature and not a bug or that the vulnerability is completely
Theo...cal.  Neither of them is the case here, and the folks only looking
for weaknesses in the crypto-algorithms such as key-stream-reuse and
possibilities to inject 2^64 ;-) adaptive choosen plain-texts will
hopefully acknowledge that crypto-analysis in 2002 welcomes laziness and
misunderstanding of drafs on board. Laziness already broke Enigma, but next
years will show how much impact it has when people are not able to
completely understand protocols or put too much trust in crypto and do not
think about the impact of violating the simple MUST in section
1.1.70.3.3.1.9.78. of the super-crypto draft.


--[ 6 - Acknowledgments

Folks from the segfault dot net consortium ;-) for discussing and offering
test environments. If you like to donate some hardware or money to these
folks let me know. It would definitely help to let continue research on
this and similar topics.

 Also thanks to various other folks for discussing SSH with me.

 This article is also available [here] as pdf paper with some screen-shots
to demonstrate the power of ssharp.


--[ 7. References

[dsniff] as far as I know the first SSH1 MiM implementation "monkey in the
         middle" part of dsniff package.
         http://www.monkey.org/~dugsong/dsniff

[ettercap] good sniffer/mim combo program for lazy hackers ;-)
           http://ettercap.sourceforge.net

[ssharp] an implementation of the attacks described in this article
         http://stealth.7350.org/7350ssharp.tgz

[here] this article as pdf with screenshots
       http://stealth.7350.org/ssharp.pdf

|=[ EOF ]=---------------------------------------------------------------=|