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.
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.
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.
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.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- Non-Linux FOSS: Code Your Way To Victory!
- Vagrant Simplified
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Libreboot on an X60, Part I: the Setup
- Dealing with Boundary Issues
- System Status as SMS Text Messages
- Bluetooth Hacks
- New Products
- October 2015 Issue of Linux Journal: Raspberry Pi
- Linux and the Internet of Things