A Rough Year for SSH

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 BangThe 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 SecretDug 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 AnalysisAt 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 CompensatorThis 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 LoginLate 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 IssuesA 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.RecommendationsThis 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.ResourcesSSH: The Secure Shell, The Definitive
Guide January, 2001, ISBN 0-596-00011-1
OpenSSH
Security ResourcesSsh
Communications Security Resourcesdsniff
vs. sshComment
on SSH1 timing attacksJose 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.

email: jose@biocserver.BIOC.cwru.edu