The End of SSL and SSH?

By Kurt Seifried (seifried@securityportal.com) for SecurityPortal

December 18, 2000 - Yesterday, dsniff 2.3, written by Dug Song, 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. SSL and SSH are used to protect a large amount of network traffic, from financial transactions with online banks and stock trading sites to network administrator access to secured hosts holding extremely sensitive data. Both SSH and SSL use "public key encryption," wherein their vulnerabilities lie. They also rely heavily on the user to make the right decisions when faced with an attack, and most users are not educated enough to know what exactly they are dealing with. Users often make the wrong decision — how many times have we told users not to open up executables emailed to them?

Public Key Encryption

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.

For example — this is oversimplified but essentially correct — user Alice wants to talk to server Bob, and Charlie wants to snoop in on her session so he can read her mail. Alice initiates a connection with Bob, Charlie sees this and intercepts it. Charlie talks to Bob and pretends to be Alice; on the other side he talks to Alice and pretends to be Bob. Alice sends her public key out, which Charlie intercepts; Charlie then sends his own public key to Bob. Bob then sends his public key to Alice, which is again intercepted by Charlie; Charlie sends his own public key on to Alice.

Now when Alice signs data using her secret key and then encrypts data to Bob using Bob's public key, she will actually be using Charlie's public key, meaning Charlie can decrypt the data. Charlie will then receive the data, decrypt it using his secret key, strip off Alice's signature, sign the data using his secret key, encrypt the data using Bob's public key, and send it to Bob. Thus Alice thinks she is talking directly to Bob in a secure manner, when in fact Charlie is in the middle intercepting the communications, able to monitor them and also to modify the content. This means that Charlie can not only grab Alice's username and password, but can inject his own commands, while the trail points to Alice. Bob is in the same situation as Alice, blissfully unaware that Charlie is about to format the main hard drive.

Since this problem is so fundamental to public key encryption, there have been many schemes to foil an attacker like Charlie. With SSL, the most common solution is to use signed certificates. The server has a certificate containing its public key, and information such as the server name and organization responsible for it. This "certificate" of information is then signed by the secret key of a trusted third party (such as VeriSign). The trusted third party's key is then usually built into such software as Web browsers. If an attacker can subvert the Web browser and modify the certificate, they will also be able to redirect information before it gets encrypted — so the risk assumption is that the user will have trusted software. When the user tries to establish an encrypted session with the server, they can verify that the certificate that the server sent them is indeed valid and belongs to whom it claims to.

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. 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. 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.

I also wrote several articles last year regarding SSL and other authentication protocols. The URLs are listed at the bottom, and they discuss how an attacker could go about this successfully. Unfortunately, unless both parties have some pre-established connection (server knows the user's password, or they use signed certificates from a trusted CA) any authentication system will probably be susceptible to a man-in-the-middle attack (although people are working on better systems).

Can't They Fix It?

So why haven't these problems been fixed? Well, without some trusted third party to sign keys and certificates — providing a somewhat secure path over which to establish a secure connection — the connection must be established by two parties that do not trust each other. (That is, they cannot prove their identity to each other securely.) 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. Thus the server and the client both either know the username and the password associated with that username, or can otherwise verify it. 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. (Almost any time people are required to send or receive sensitive information via the WWW, SSL is used, although in too many cases it is not.)

To make matters worse, the very foundation of modern networks is generally insecure, using protocols designed 20 or 30 years ago in an environment where security was not as much of a concern. Lower-level protocols like ARP (Address Resolution Protocol, used to map IP addresses to MAC hardware addresses on local networks) contain no provisions for security. Moving up the scale, TCP/IP and UDP provide no built-in encryption or authentication, and it will be a very long time before there is widespread use of IPSec. DNS is also generally insecure: Anyone can provide false answers with no real way to verify the data currently. However, DNSSEC is starting to appear, and the .mil domain pledging to use it should help matters somewhat.

Enter dsniff

Dsniff is a sophisticated set of programs written by Dug Song which, combined with other standard utilities like tcpdump (a standard packet sniffer), allow you to monitor and redirect network traffic so you can analyze it. While most packet sniffers can monitor network data, very few are capable of rerouting traffic or analyzing encrypted data. The utilities dsniff provides allow you to redirect network traffic at a number of levels. First of all is the local network. If you are on a hub or 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. Some switches when flooded revert to hub mode, thus allowing you to monitor the target's network traffic.

Using the dnsspoof utility, you can forge DNS replies and redirect DNS names to arbitrary IP addresses (ones you control). And with tcpkill, you can block TCP connections to machines by spoofing packets that tell the machine to close the connection. Once you have got the traffic going to a machine you control, you can use the suite of sniffing tools to extract passwords, message traffic, files and so on from network traffic. 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. Following is a list of dsniff utilities:

arpspoof - spoof arp entries
dnsspoof - forge dns replies
macof - flood using mac addresses
tcpkill - block tcp connections
tcpnice - slow down tcp connections
dsniff - all purpose sniffer
filesnarf - NFS sniffer
mailsnarf - email sniffer
msgsnarf - IM sniffer
urlsnarf - web url sniffer
webspy - lets you surf in synch with your target
sshmitm - SSH protocol 1 attack
webmitm - HTTP / HTTPS attack

And it is now available in a convenient source ball package that an attacker can easily compile and use. Most of these tools are available from other sources, or have been hand-coded by attackers. Until now, however, they were difficult to track down and use, which gave SSL and SSH a bit of respite.

What Can You Do about This?

Ignoring the problem might be one response, but that probably won't work in the long run. Without major restructuring of the SSH and SSL protocols, there is very little that can be done to "fix" them. The best course of action is to educate users to the dangers that attackers pose, and how to recognize when an attack may be taking place. Setting up a lab or actually running the software and showing users and management their passwords would be one way to encourage them to pay attention — but make sure you get permissions and that people are warned in advance.

Maintaining the overall security of your network is also a good idea. If an attacker can't get in, this will prevent them from many internal attacks. If you are using SSL for secure transactions, you should probably consider setting up a CA (or outsourcing it) and issuing SSL certificates for users as well as smartcard readers to store them securely.

The simplest solution with SSH would be to stop supporting protocol version 1. Moving to protocol 2 shouldn't be too difficult, as OpenSSH supports it, and most free clients do as well (although not all). You can also use one-time password schemes. Doing so with a secure token would greatly minimize the risk involved, although session hijacking would still be possible, and it would probably be more difficult than switching over to SSH protocol 2.

However, it is only a matter of time before someone improves upon dsniff to support SSH protocol 2. Implementing lower-level security protocols such as DNSSEC should help, if this is done properly. DNSSEC will prevent attackers from spoofing DNS replies (although rerouting traffic with ARP spoofing on local networks will still be possible).

Other options include using IPSec and making it mandatory for workstations and servers. With a strong authentication system, it would be much more difficult for attackers to spoof traffic or sniff it.

Summary

Hopefully this will spur on the adoption of secure network protocols such as DNSSEC and IPSec. It is unlikely that anyone will discover some new mathematical property that can be used to make a secure authentication protocol that won't be susceptible to the same problems as SSH and SSL given the same circumstances. Right now, network encryption at the session level is seen as a panacea that will solve all your problems — but like any solution, it breeds new problems. Admittedly, these new problems tend to be a lot harder to exploit than the old ones, but they are still exploitable.

The End of SSL and SSH?

Public Key Encryption

Can't They Fix It?

Enter dsniff

What Can You Do about This?

Summary

Related Links