dsniff and SSH : Reports of My Demise are Greatly Exaggerated

On 17 December 2000, Dug Song released a new version of his well-known package of network sniffing tools, dsniff. The new release includes a tool named "sshmitm," which performs a man-in-the-middle attack (MITM) on the SSH-1 protocol.

The following day, Kurt Seifried wrote an article titled The End of SSL and SSH? The article has generated a fair amount of discussion and buzz, not least because of its dire-sounding title. And there are certainly important implications to the appearance of sshmitm. Seifried's piece, however, contains several factual errors and misleading statements in discussing the details of SSH (secure shell), SSL (secure sockets layer), and MITM. This is unfortunate, since these shortcomings blur the essential message, which is valid and important to get out. This article attempts to correct some of those mistakes, and to clarify the issues involved.

The MITM is not a new idea; it is a well-known general method of attack against authentication and key-exchange protocols. SSH includes mandatory server authentication specifically to thwart MITM. Naturally, this relies on the ability of the client to verify the claimed association between the server's public key and the identity of the server host. In an SSH session, the server hands the client a public key, then proceeds to prove that it has access to the corresponding private key. All well and good, but the server could have simply generated a brand-new key pair and done the same thing. For this transaction to be meaningful, the client must independently verify that this particular public key identifies the host that the client originally intended to contact. Solving this "key-distribution problem" is a necessary part of public-key authentication techniques.

There are technologies available to address key distribution. One is the X.509-based Public Key Infrastructure, or PKI. Another is DNSSEC, a set of extensions to DNS for securing the Internet naming system, which naturally allows for verifiable bindings between hostnames and keys. However, no such systems are yet commonly deployed, so current SSH implementations take a simple approach: a local database of key/hostname associations, maintained by the sysadmin and/or individual users. SSH clients may be configured to automatically accept and record host public keys on first contact, thus allowing the user to build up the known-hosts list naturally--but incurring the risk of MITM on the first connection to any host. If this risk is unacceptable, the client may also be set to require an existing correct host-key entry and reject connections that fail this test. This protects against MITM in all cases, with the attendant burden of requiring the user to manually add new host-keys as needed. Of course, the point is that in doing so, the user should verify through some other means that the key actually belongs to the host in question--perhaps by getting it on a diskette from the sysadmin, or by checking the key fingerprint against a posted list.

With these ideas in mind, let's examine some excerpts from Seifried's article.

> "The End of SSL and SSH?"
> 
>  By Kurt Seifried (seifried@securityportal.com) for 
>  SecurityPortal
> 
>  December 18, 2000 - Yesterday, dsniff 2.3 was released. 
>  Why is this important, you ask? dsniff 2.3 allows you to 
>  exploit several fundamental flaws in two extremely popular 
>  encryption protocols, SSL and SSH.

This is a misleading exaggeration. It becomes clear shortly that Seifried is talking about MITM. The existence of MITM is not a flaw in either protocol; in fact, both protocols include mechanisms to counter MITM. What is true is that, in most implementations, users may choose to override those mechanisms for the sake of convenience, forgoing MITM protection. One might take issue with this decision, but it is an implementation issue, not a protocol design flaw.

Now, the SSH protocol does specifically allow clients to omit the host-key verification step, leaving the session open to MITM. Of course, it would be impossible to enforce such a step through the protocol anyway, since it is a one-sided policy issue, but the protocol could at least state the requirement. This could be considered a flaw, but that's not a fair assessment. The decision to sanction this behavior is a considered one, balancing the security risk against the overall security benefits of widespread SSH use. There is an entire section of the IETF (Internet Engineering Task Force) draft on the SSH-2 protocol architecture , which discusses this very issue (section 3.1, "host-keys"). It explicitly acknowledges that for a client to connect without verifying the server host-key is a vulnerability, but weighs this against the fact that without any kind of widespread PKI, SSH usage would be severely limited by demanding server authentication in every instance. To quote:

  ... Implementations SHOULD NOT normally allow such 
  connections by default, as they pose a potential 
  security problem. However, as there is no widely 
  deployed key infrastructure available on the Internet 
  yet, this option makes the protocol much more usable 
  during the transition time until such an infrastructure 
  emerges, while still providing a much higher level of 
  security than that offered by older solutions (e.g.
  telnet [RFC-854] and rlogin [RFC-1282])...

  We believe that ease of use is critical to end-user  
  acceptance of security solutions, and no improvement 
  in security is gained if the new solutions are not used.  
  Thus, providing the option not to check the the server 
  host-key is believed to improve overall security of the 
  Internet, even though it reduces the security of the  
  protocol in configurations where it is allowed.

This argument is compelling and very practical: it will be better to have a large amount of Internet traffic enjoy integrity and privacy protection (though some small fraction of that traffic is missing MITM protection), rather than see the deployment of any kind of protection stunted. SSH will not be widely used if it is too difficult to do so. Moreover, absolutely requiring preexisting known-hosts entries is simply too onerous in today's Internet.

>  ... There is one fundamental problem with establishing 
>  a secure, encrypted connection over the Internet. No 
>  matter how you do it, at some point you must initiate 
>  the connection over a public and potentially hostile 
>  network. Ideally, when two hosts establish a connection, 
>  they exchange public keys using a variety of verification 
>  processes (Diffie-Hellman being an extremely popular one), 
>  and each host properly receives the other's key.  
>  Unfortunately, since this must take place over a public 
>  and usually insecure network, it is possible for an
>  attacker to intercept the key exchange and subvert it.

This is confusing. The Diffie-Hellman key-exchange algorithm does not exchange public keys; it allows two parties to agree on a single, secret (symmetric) key. This is done in such a way that it is not feasible for an observer to discover the shared key, even though the messages are transmitted in the clear. The Diffie-Hellman method by itself is vulnerable to MITM, however, which is why both the SSH and SSL protocols require that server authentication guard against this. That step does involve exchanging at least one public key--but that is a separate element of the protocols.

>  ... Since this problem is so fundamental to public 
>  key encryption, there have been many schemes to foil 
>  an attacker ... [description of server authentication 
>  using public-key certificates] ...  Unfortunately, there
>  is a missing part in this equation. While SSL requires that 
>  the server authenticate to the user, it is usually an 
>  option for the user to authenticate to the server. And 
>  since so very few users own personal certificates, it is 
>  exceedingly rare for a user to be able to prove their 
>  identity to the server in question--leaving the connection 
>  open to attack.

Seifried does not specify here exactly what "attack" he's talking about. However, context implies that he means MITM. The claim here, then, is that omitting client (user) authentication leaves the protocol vulnerable to MITM. This is wrong. Client authentication takes place only after successful server authentication--which will fail under MITM. A user may override or omit the server authentication check, allowing MITM to succeed, but this is completely independent of whether or not client authentication is used later on.

Now, there is a related but different statement that is true: abstractly, omitting client authentication may bypass a chance to detect MITM, assuming that server authentication has already failed to do so (either because the user defeated it, or because the attacker has stolen the legitimate server's private host-key). This is because some client authentication methods are also designed to resist MITM. SSH password authentication, obviously, is not MITM-resistant; once you hand your password over the trapped connection, all is lost. And the SSH-1 public-key user-authentication method is also vulnerable; the attacker may use the signed authenticator from the client side to access the client's account on the server. However, the SSH-2 public-key and host-based client authentication methods are MITM-proof: the authenticators involved are bound to session identifiers that are forced to be different on either side of the attacker.

>  The same general problems exist for SSH. Instead 
>  of certificates, however, SSH simply uses a secret 
>  and public key, and since they are generally not signed, 
>  it is trivial for an attacker to sit in the middle 
>  and intercept the connection. If this is the first 
>  time you are connecting to a host and you do not have 
>  the server's public key locally, you will be none the 
>  wiser.

The writing here is a bit confused. First, Seifried proceeds to talk about the "same general problems for SSH." He does this even though he has switched from discussing user authentication to server authentication, which are entirely different topics (and, in fact, in SSH-2, different protocol specifications).

Second, the claim about being "none the wiser" regarding the addition of a new key is at best exaggerated. This is obviously an implementation rather than a protocol question: when it encounters an unknown host-key, what does the client do? Existing software varies, but OpenSSH, for example, may be configured to:

1. Add the key automatically and issue an advisory message;
2. stop with a warning and ask whether to add the key and continue, or abort the connection; or
3. refuse to connect at all.

>  If you do have the server's public key, you will 
>  generally receive a warning like "Warning: server's 
>  key has changed.  Continue?" Most users will hit Yes.

Again, implementations vary, but the message issued in this circumstance by all three common Unix SSH packages, is in fact quite a bit more strenuous than this suggests:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@  WARNING: 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 host-key has just been changed.  Please contact 
your system administrator.

If you don't get the idea from this message that something might be wrong, then all the cryptography in the world won't help you. And remember, this message will only be followed by the option to continue if the sysadmin has set it as the default. In a security-conscious environment, strict host-key checking will be required, and the connection will simply fail. The user could override that, but, at this point, she's on her own. Including the ability to override allows for widespread use of SSH, which is worth the risk of some users willfully ignoring their local security policy. (Which they could always do simply by compiling their own custom version of the software, anyway.)

> ... There are newer key exchange algorithms 
> that claim to solve many of the problems inherent 
> in these transactions, but most are aimed at services 
> where the user is logging in to a server... Unfortunately,
> these protocols do not work so well for SSL transactions, 
> which are used on a massive scale with end users that 
> cannot prove their identity to the server.

Again, I read this as claiming user authentication is necessary for MITM resistance. This is just not true.

>  If you are on a hub or a switch, you can use arpspoof 
> to hijack other machines' IP addresses. If the switch 
> is secured and ignoring arp packets, you can use 
> macof to flood it...

This is a side issue, not related directly to SSH or SSL--but it's an error worth mentioning nonetheless, since it implies that switches can somehow be configured to prevent ARP (Address Resolution Protocol) spoofing. I have never heard of a layer 2 switch listening to ARP traffic; it need only examine the source and destination MAC addresses of passing Ethernet frames to do its job. A spoofed ARP reply operates at a higher layer, poisoning the target host's ARP cache and fooling its IP stack into transmitting some IP datagrams to the attacker's MAC address in lieu of the legitimate host. The switch continues to operate normally.

> With the latest version of dsniff you also gain 
> the ability to intercept and monitor SSH (protocol 
> version 1) and SSL connections using the vulnerabilities 
> discussed above... Without major restructuring of the 
> SSH and SSL protocols, there is very little that can be 
> done to "fix" them.

Again, this happens only if server authentication has been deliberately disabled, bypassed by client configuration, or if the client host has been separately compromised and its known-hosts file or trusted CA certificate cache poisoned. These are issues of implementation, user-awareness, and local host security. They are important ones and worth discussing, but they are not protocol "vulnerabilities" or "flaws," and there is nothing to "fix."

To sum up, then: The easy availability of dsniff/sshmitm drives home the point that MITM is a real threat, not just a theoretical one. With the dsniff tools, it took this author only a few minutes to spoof DNS replies to a victim host, redirect an SSH connection to an intermediate system, and conduct a successful MITM against it. The sshmitm program obligingly printed out my username and password, and then echoed the contents of the trapped SSH session as I typed. Scary stuff. It should serve to raise user and sysadmin awareness of their responsibility to maintain the SSH known-hosts lists, configure client behavior in accordance with a considered security policy, and think carefully before overriding security warnings about changed or missing host-keys. But there is no reason to suppose that the appearance of dsniff 2.3 and sshmitm spells the "end of SSH and SSL" in any way.

Sponsored by: