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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide