A Rough Year for SSH

by Jose Nazario

Just as 2000 was a rough year for firewalls, with holes blown in both commercial and open-source products, 2001 was a most uncomfortable year for the secure shell, or ssh. Several groups focused their attentions on this cornerstone of the net, and several problems emerged. ssh has emerged from this scrutiny a stronger product.

Not all of these issues affect all ssh users, so it's important to understand the vulnerabilities, their impact, and how to mitigate these risks. In this piece, several of the vulnerabililities found in 2001 are discussed, and some general recommendations for the ssh user are offered.

Briefly, two major vendors of ssh products have emerged, SSH Communications, who originally developed the software, and OpenSSH, who produce an open-source derivative. When referring to the ssh client from SSH Communications, the term Ssh will be used. When referred to the OpenSSH client, the term OpenSSH will be used. This is important as they sometimes do not share security vulnerabilities. SSH1 refers to the version 1 protocol for ssh, and SSH2 refers to the second version of the protocol.

Starting 2001 with a Bang

The year 2001 saw folks geared up to abuse ssh through monkey-in -the-middle attacks, facilitated by the release of dsniff-2.3 in late 2000. dsniff, from the well known and respected security professional Dug Song, is a super sniffer and network penetration tool. Among the tools it includes is a tool to perform "man-in-the-middle" attacks on SSH1, allowing an attacker to eavesdrop on an SSH1 connection. The attack relies on a combination of factors, including a DNS spoof and the server's key not being in your cache, or the user accepting the new key as the valid server's key. In doing this, the attacker fools the ssh client into connecting to them, rather than the intended server, while the eavesdropper completes the connection. By negotiating the session key for encryption, the attacker can observe the full ssh session.

The attack is nothing new, but the release of dsniff-2.3 made this much simpler. Since then, new releases of Ssh have integrated PKI, or Public Key Infrastructure, support, allowing for the verification of server keys through a chain of trust. Use of the tool only increased in 2001, but also had the effect of helping people learn public key authentication more readily.

Revealing Just a Bit of a Secret

Dug Song also worked with another hacker on yet another attack on SSH1, which reveals the password length during authentication. Working with Solar Designer, who is known for his Linux Auditing Project work, the two developed a tool to ascertain the exact size of the password, which can facilitate the cracking of the password by a factor of 50. While it doesn't reveal anything else about the password, including the composition, together with additional information this can be useful for an attacker. When this is combined with a subtle bug I found in early 2001, which revolves around a failure to log repeatedly unsuccessful login attempts in Ssh but not OpenSSH, attacks on networks can be facilitated.

This affects mainly SSH1, as the password authentication mechanism in SSH2 doesn't reveal as much information. OpenSSH has some implementation fixes in place, but Ssh has not committed the fixes, citing the deprecation of SSH1 and the related code.

Munching on Traffic Analysis

At the USENIX Security Conference in 2001, researchers from the University of California, Berkeley developed an attack on the traffic that ssh uses during communications. The attack has generated a significant amount of press due to its beauty and creativeness, however it remains a rather academic attack. A tool, named Herbivoir, was also released to demonstrate the technique, with the name being an obvious pun on Carnivore, the FBI e-mail sniffer.

Briefly, by observing the traffic (the concept of traffic analysis) and its patterns, the commands being issued by the client can be guessed. Furthermore, by observing the responses, a command like "su" can be picked out. And because the timing between keystrokes can be measured, the length and basic composition of the password can be ascertained. The weakness comes from the way ssh packets are handled, which is with a high value on interactiveness, using a minimal delay between input and sending the packet. As such, a single ssh packet often includes only one keystroke.

The attack is, as noted above, very academic. Simply put, the analysis of the interkeystroke timings requires a large training set, as every individual types with different patterns. Secondly it requires a constant delay in observations so as not to skew the measured timings. As such, it seems out of reach of most attackers, and only reveals a portion of the data needed to mount a successful attack.

Abusing a Compensator

This vulnerability in SSH1 is probably the biggest threat to a typical ssh server on the network today, and is, at the time of this writing, in active abuse by hackers. This is related to the classic buffer overflow attack, and gives an attacker root access to the compromised machine.

In 1998, CORE-SDI, a South American security firm, noticed a subtle attack on the encryption used by Ssh. By abusing the checksum routine, which uses the CRC32 algorithm, an attacker can begin a plaintext attack on the payload of the ssh session. To counter this attack, a compensator was included in ssh. When it is tripped, a log message is generated.

In early 2001, Michal Zalewski of the Razor team at Bindview noticed a memory allocation error in the compensator. Briefly, only 16 bits of data were allocated to store a 32-bit value. By carefully crafting an attack as discussed by CORE-SDI, this table index can be overflowed and arbitrary code executed on the server with full root privileges. At the time of the discovery, no known working exploits were available. However, since then an exploit has begun circulating in ever increasing circles. This attack is under heavy abuse by some hackers as 2001 draws to a close. There is even some evidence that a worm has been developed using this attack vector.

Due to the nature of the vulnerability, this issue was addressed immediately by both the Ssh developers and the OpenSSH team. Since Ssh version 1.2.32 and OpenSSH version 2.3.0, this issue has been fixed. All ssh users should have upgraded as this is being actively exploited.

Local Abuse via Login

Late in 2001 a minor bug was found in OpenSSH when the UseLogin directive is employed. Simply put, before any privileges were dropped (the daemon runs as root), the environment of the user was processed. This allowed an attacker to craft their LD_PRELOAD, for example, to include a malicious library call that elevated their privileges.

A valid local account is required to execute this vulnerability, and a working example of how to do this has been posted to public lists for security matters. Note that UseLogin is not enabled by default, and this has been fixed in OpenSSH 3.0.2.

Various Minor Issues

A few small issues have been brought to light this past year, as well, concerning the security of ssh. They've been fixed, but definitely are worth pointing out.

First, a recent problem in Ssh version 3.0.0 was found. Accounts which had been locked with a password field of only two characters, no more, no less, could be entered without any validation of any kind. On some commercial UNIX platforms with multiple UID 0 accounts locked by this mechanism, a serious security breech could be encountered. This was fixed in Ssh 3.0.1.

IP address based access control was an issue in OpenSSH 2.9 and earlier versions, allowing an attacker to bypass connection restrictions. This occurred under rare circumstances in a particularly formatted authorized key file using the "from=" directive for access control. This was fixed in OpenSSH 2.9.9, and doesn't affect many users.

Resource starvation attacks, where an adversary attempts to flood the server with connection requests, are also mitigated in OpenSSH. A parameter exists to configure the daemon to control the number of children it spawns, helping to prevent this sort of attack. Ssh 1.2.x is still vulnerable, though.

Recommendations

This has been a dizzying year for ssh users attempting to maintain their secure systems and networks. By far the biggest reason to upgrade an ssh installation is the CRC32 compensator attack, which is in growing abuse around the world. Vendors have released updated binaries and packages, ensuring that their systems can be made secure against this attack vector.

Obviously some of these attacks are more theoretical or academic, and shouldn't cause much alarm in ssh administrators. Most sites will not have the information leaked in the passive traffic analysis attack, using the Herbivoir tool, cause them much harm. Sites that are concerned about this, such as those with government secrets, should be relying on more secure mechanisms anyhow to protect their traffic.

The local privileges escalation attack outlined above should also be minded, and the site adjusted accordingly. Either turn off the UseLogin directive or, if that option is unavailable, ensure that your site is updated to the latest version of OpenSSH. The attack doesn't require much sophistication on the part of the interested party.

For these reasons, the following basic recommendation are made to ssh administrators. Use SSH2, rather than SSH1. Clients are available for SSH2 now with widespread availability, including for Mac and Windows, and many of these clients are freely available. Things have changed significantly on this front in the past year. OpenSSH supports both protocols SSH1 and SSH2 in a single binary, with a simple directive in the server determining the order in which they are attempted.

Secondly, encourage your users to use public key authentication. Several great tutorials have been written on the subject, and its rather easy to set up. This will help stem attacks on the passwords for your users, making such an attack much harder to mount.

Thirdly, keep in mind that even though ssh can perform strong authentication, not every attacker needs to authenticate to gain control of their target. With this in mind, it is wise to use a firewall or some other means to control login access to the ssh server.

Lastly, don't allow root logins via ssh directly, instead force users to login as a regular user and use "su" to root. This will help stem several attacks before they can even begin.

Obviously, staying up to date is the best method to protect your servers. Together with a sound configuration evaluation, ssh can enhance security, not compromise your site's risk profile. Because of the increased usage of ssh in nonstandard devices, such as IOS on Cisco routers, upgrading totally to eliminate the problems with faulty ssh implementations may not be totally possible. However, keep an eye out for your vendor's updates.

Currently, both major forms of ssh allow for even greater authentication mechanisms. OpenSSH has added support for smart card authentication, which can be useful for sites using token based authentication mechanisms. SSH2 allows for PGP keys to be used to authenticate against a server, enabling a web of trust in the authentication of users employing public key authentication schemes. Lastly, Ssh 3.0 adds support for a PKI in the server keys, ensuring trust relationships for the keys and helping to stem off the man-in-the-middle type attacks through verification of the keys presented to the client. All versions of ssh, both Ssh and OpenSSH, also support Kerberos authentication and S/Key and One Time Pad passwords. On Linux, the use of PAM extends this to even more mechanisms through the PAM interface. These authentication mechanisms have matured, and their interest has grown, as a result of the attacks on the authentication mechanisms from this past year.

In conclusion, ssh has been the focus of a significant amount of scrutiny this past year, and through it the product and protocol have improved. By raising awareness to the security issues, as well as providing a robust, open-source alternative in OpenSSH, the ssh community has improved the state of internet security. Administrators and users should keep up to date with their ssh software to ensure their security.

Resources

SSH: The Secure Shell, The Definitive Guide January, 2001, ISBN 0-596-00011-1

OpenSSH Security Resources

Ssh Communications Security Resources

dsniff vs. ssh

Comment on SSH1 timing attacks

Jose Nazario is a biochemistry graduate student nearing the completion of his PhD. Side projects include Linux and other UNIX variants, software and security-related matters, and hobbies outside of his office like fly-fishing and photography.

Load Disqus comments