oreilly.comSafari Books Online.Conferences.


Time and Tide Wait for No Protocol
Pages: 1, 2, 3

A Real Attack

Related Reading

SSH, The Secure Shell: The Definitive Guide

SSH, The Secure Shell: The Definitive Guide
By Daniel J. Barrett & Richard Silverman
Table of Contents
Sample Chapters
Full Description
Read Online -- Safari

Remember that the investigators' tests involved predictions based on typing isolated passwords. In real life, an attacker would first have to isolate the packets corresponding to a password in the stream of TCP segments in an SSH connection. But there are multiple ways this might happen. First, observation may show repeated habits that leak this information. For example, Eve, the attacker, may observe from network traffic that her victim, Paul, often connects first to host A, then immediately connects from A to a second host B, again using SSH. If Eve suspects that Paul is using password authentication for the second connection, then by experimentation on her own she can know at least approximately where in the second SSH stream to look for the typed password. Furthermore, there may be clues again in the traffic timing that reveal the positions of sensitive data. The observed pattern of using the "su" command, for example, is peculiar: three echoed characters, followed by a single larger packet containing the "Password:" prompt, followed by several characters from the client that are not echoed: the password. Identifying such timing signatures in a recorded SSH stream could identify likely keystroke sequences for attack.

Of course, in order to conduct a dictionary attack, Eve needs a password verifier: some way to test whether a guessed candidate password is correct. This might be, for example, a hash of the password lifted from the account database of a compromised system on which Paul has an account. The figure of checking 250,000 passwords per second is predicated on being able to verify guesses efficiently. Without a verifier, Eve would need to attempt a login to test guess--and hopefully thousands of failed logins would raise a red flag long before Eve could discover Paul's password. Remember, though, that attempting a login via SSH may not be the only way to verify the password. The same password will likely be used for authentication for a number of protocols: Telnet, SMB, RADIUS, and so on.

Richard Silverman has also written dsniff and SSH: Reports of My Demise are Greatly Exaggerated on

It's important that all services that perform authentication detect unusual authentication failure rates and take some action: notify the system administrator, and perhaps automatically lock out the account until someone can determine what's going on. This is also a good argument for using a centralized authentication system, such as PAM, so that such security monitoring can be configured once for all services, rather than requiring that separate support be written into and enabled for every service.

Another obvious difference between the laboratory and a real attack is that the researchers had the advantage of cooperative subjects, who thoughtfully sat down and provided training data for the HMM's. Unless she's also a hypnotist, Eve will presumably not be able to first get Paul to sit down and type random passwords for her--and if she has infiltrated his workstation sufficiently to capture his keystrokes for this purpose, she won't need to go to the trouble of this sophisticated attack to capture his password! So, this begs the question of whether a personalized model is necessary for a successful attack.

The paper examines this question as well, both abstractly and experimentally. The authors write that comparing characteristics of timing data from different users "suggests that typing statistics have a large component that is common across a broad user population and which thus can be exploited by attackers, even in the absence of any training data from the victim."

They also experimented with this, using models from one subject to analyze the password keystrokes of another. They conclude that while using a model from the same person is (unsurprisingly) more effective, nonetheless "training data from one user can successfully be applied to infer passwords typed by another user. Hence the attack can be effective even when the attacker does not have typing statistics from the victim." Of course, the number of subjects in these experiments was quite small (four), and it seems that further research is needed to discover how broadly these relationships hold in the population, and thus confirm these findings and their significance.

Quite aside from the ability to infer keystrokes, there also is the possibility of using timing data simply to identify the user. Keystroke timing patterns have been used in commercial products as a biometric identification device; the same principle might be applied here. This would require the attacker to have specific typing profiles on hand for his victims--but if a company were using timing biometrics that database would be stored somewhere and might be stolen for this very purpose. Of course, with personal workstations so common today, the source IP address is often a pretty conclusive indication, but this is still an issue to be noted.

Common Misconceptions

Here are a few often-seen misconceptions regarding the paper's methods and conclusions.

  • This attack applies to SSH "password authentication:" It's unsafe and we should stop using it immediately.

    Confusingly, this is both true and false, depending on how you interpret the sentence. The technique in question does not apply to SSH password authentication, when the attacker is observing an SSH protocol session using that method for its own authentication phase. This is because the password is transmitted all at once in a single SSH protocol message, not a character at a time as the user types it (recall that this happens before the SSH terminal session has even started).

    However, if Paul happens to use the first SSH session to start another one--that is, ssh to one host and then run ssh there again, to connect elsewhere--and if that second SSH connection uses password authentication, then he is vulnerable. The password will be safe while traveling inside the second SSH connection, but it will be exposed for a timing attack as he types in it over the first connection. Still, even interpreted this way, the statement is not quite fair, as this is not a vulnerability of SSH specifically; any passwords typed in the first session, for any reason, are similarly vulnerable.

    Another point confuses this issue, which is that the paper mentions a separate potential vulnerability: one which is specific to SSH password authentication but unrelated to the timing attack. If a client sends the SSH protocol message containing the password in a single TCP segment, then this can reveal information about the length of the password, to within the block length of the cipher being used (commonly 8 bytes). This can give an observer close upper and lower bounds on the password's length, again reducing the amount of work needed for a brute-force attack.

    However, it turns out that this is not as serious a problem as the timing attack, as there is an easy way to address this issue: simply pad the password message out to a fixed length. The SSH transport protocol allows for arbitrary padding, so this is a simple thing to do. OpenSSH already implements this defensive move, but in a slightly different way: it appends an SSH "no-op" message immediately after the password message, whose length is calculated to extend the sum of the two message lengths to a fixed value. The two messages are then transmitted in a single TCP segment. In the SSH-2 protocol the message lengths are encrypted along with the rest of the message, so Eve cannot break the segment up into its component messages, and she thus gets no information about the password length (assuming there's no other structural subtlety that reveals the message boundaries; there shouldn't be).

Pages: 1, 2, 3

Next Pagearrow

Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!

Linux Resources
  • Linux Online
  • The Linux FAQ
  • Linux Kernel Archives
  • Kernel Traffic

  • Sponsored by: