Slashdot Mirror
SSH Vulnerability and the Future of SSL
iamchris writes "Growing complacent in regards to security is dangerous. I've become more and more dependant on the SSL-type tools for my security... ssh itself, ssl for my web content, scp, sftp, etc... We all know nothing is 100% secure (or if you don't, God help you). An article on Security Focus cites a vulnerability with SSH and passwords. We usually type them in letter-by-letter. A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding. Is there a better alternative to SSL based tools (Perhaps TLS)? Is there anything that can be done with the clients help with the small packet issue?"
If you use SSH2 protocol and Public key authentication only, you're no longer vulnerable to the password-guessing or Monkey-in-the-middle attacks as they exist today.
The measurements of keystroke timing can be done on a broad, high-latench internet only if the Nagle algorithm is disabled. Some SSH implementations defeat the use of Nagle, in order to provide better interactive response. This can be taken out in the source code (or maybe with a configuration parameter: I'm not familiar with all SSH implementations).
When you have Nagle enabled, your keystrokes are aggregated into larger packets, because the next packet is not sent until an ACK for the previous one is received---or you type enough to send a full segment. Or something like that; I leave it to the reader to verify the details of Nagle. In any case, it's clear that Nagle can obscure the timing of individual keystrokes if the latency is high enough to cause aggregation of several characters into one packet.
Secondly, if you use public key authentication, then you won't be typing your SSH password over the network. Of course, other sensitive information may be typed, such as passwords to other systems logged into within the SSH sessions. But the SSH key itself can't be compromised by this timing attack.
The technique was as follows:
Person A logs into the client, using a username/password pair. The client then generates an RSA keypair, using hashes of the username and the password as seeds for the random number generator.
The client then contacts a key exchange server. This takes the client public key and the server public key, generates a fresh set of keys for both client and server, encrypts them using the appropriate public key, and sends the keys back as appropriate. (eg: The client gets the client's private key and the server's public key.)
This establishes the link between the client and the server. Each then generates a secret key, using one of a selection of algorithms. (I used Serpent and Rijndael). The secret keys are then exchanged, using the public keys.
The client then uses the original username and password to connect to a Kerberos server, for a ticket.
Only at this point is data allowed to be exchanged between the server and the client, and only for the duration authorised for that ticket.
After random intervals, the secret keys are regenerated, though not necessarily with the same algorithm as before. The new keys are again exchanged with the public keys.
Once the Kerberos ticket expires, the public and private keys are replaced, using the key server. Once the keys are replaced, the Kerberos server can be contacted to refresh the ticket.
The reason for this amazingly convoluted system? I wanted a system that could run on an untrusted network, with an untrusted client AND an untrusted server.
The challange was to devise a system that provided sufficient checks that a compromise at ANY point would not yield useful information.
In practice, that's very hard to do. Compromise the database, and you have the data. There's not a lot you can do about that. Compromise the front-end server, and you can mimic anything. Again, there's not a lot you can do to stop that.
The way I approached this (and PLEASE remember that this is NOT my field, and others will have vastly superior techniques) was to insist on all data, at both ends, being encrypted as far back in the system as possible, using keys with very limited lifespans.
The idea here is to reduce the window of opportunity by as much as possible. The idea of using multiple algorithms, public-key encryption, etc, was to soak-off as much of the window as possible with trying possibilities out.
(Note to non-Wargamers: Soak-offs are where you use a trivial piece to divert a much more significant piece of your opponent, so that you can defeat what's left with relative ease. In this case, I used the "trivial" problem of picking the right algorithm to soak-off the processing power of the opponent. My "main forces" (encryption, intrusion detection, etc) could then walk right over whatever was left.)
Wargaming and computer security, IMHO, are very closely related. However, legal issues prevent me from applying my favourite tactic in "Squad Leader" and "Advanced Squad Leader" -- steamroller one flank, setting fire to everything behind me so I can't be encircled. I'd love to see a Black Hat vs. 3 stacks of 3 x 8-4-3's with HMG's, and a 10-2 leader, but I suspect that would be considered excessive by The Powers That Be.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
using compression (ssh -C) will increase entropy in traffic analysis attacks against ssh.
There seems to be some confusion as to the nature of this attack on ssh. Some facts may be enlightening:
I am not one of the authors. Everything I write here is the result of informative discussions with Dawn Song, one of the authors on the ssh paper.
All ssh implementatons send your password in one packet (when using password authentication). However, if you ssh from A to B, and then from B to C, the fact that your password is sent from B to C in one packet isn't helping you a whole lot, since it was sent one character at a time from A to B. Using RSA authentication doesn't help, since you have to enter a password to access the key stored on B. This password will be sent one character at a time from A to B. This multihop ssh-ing is a common practice, so this is a serious threat.
Sombody else claimed that it was only effective against passwords which were susceptible to a dictionary attack. This is a non-sensical statement. The best way to describe what the attack does is in terms of bits of information gained, but I'll simply say that, with this attack, you usually only have to search about 1% of the possible passwords to find the right one.
Others have suggested using one finger to type, or using a dvorak keyboard, or deliberately typing in a random fashion. Using one finger or typing randomly will work. However, a dvorak keyboard would only change the keyboard model. The attacker could still perform the same attack, but using that model instead of the qwerty one.
As for remedies, inserting random jitter in ssh is not effective. By watching several logins, an attacker could average out the jitter to get the real timings. Changing ssh to send packets at regular intervals, or using line mode, will eliminate all timing information.
Although this attack was presented in terms of gathering passwords, it's also effective (perhaps even more effective) for recovering english text. In fact, the information recovered is about 1.2 bits/keypair, and english only has about 1.2 bits/letter of entropy. So in essence, because of this attack, YOU SHOULD CONSIDER SSH TO BE EFFECTIVELY EQUIVALENT TO NO ENCRYPTION AT ALL. You should not make light of this attack unless you would be willing to use telnet.
Somebody also said that this was extreme paranoia because one could just park a tempest van outside your window to get the text you type. But tempest vans are expensive and hard to operate. Breaking into routers is easy. This attack could easily be scripted, but I know of no tempest-van scripts in wide use. So the threat here is tremendous.
The best solution is to randomize your typing until ssh is modified to send packets at regular intervals.
Best,
Rob
Even if you just added some randomness to the user input as some proposed, still there would be statistical information that could be used. The more often you can sample the data the more accurate it does get, that's the idea of statistics!
Still these statistical methods alone won't lead to a practical attack, but together with other methods it could lead to something if we didn't do anything against it.