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 article pretty much says that keystroke timing can help increase the efficiency of dictionary searches.
Big deal. If your paswords are vulnerable to dictionary searches, then you have bigger problems than keystroke timing vulnerability.
This sounds like a non-issue to me.
Sometimes it's best to just let stupid people be stupid.
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)
Although funny, it does seem to miss the point, which isn't clearly outlined. Picture it this way......
There are Hundreds of thousands, if not Millions to 10's of Millions of computers out there that use encryption to transmit very important data. Sometimes that data is a trade secret, sometimes that data is Finacial Results that SEC rules say you can't publish yet, sometimes its internal company communication...almost all of which is being sent by Dilbert clones. Sometimes the admin, who may just be a High School teacher (they can't afford admins), chooses to use encryption over the entire network to allow kids to use dictionary passwords.
Anyhow, rule number 1 of security, the overall security of your network is only as good as your weakest link. So maybe the corporate exchanges within the network are all secure, but an employee on a low profile, unimporatant computer uses ssh to access his personal email and not only that it's a dictionary password, it's just email afterall. Now some clever cracker packet sniffs his email typing patterns, and does a brute force attack on his password...Now all that is needed is patience and one person to send the wrong info to that email account. Not only that, but by reading his email, one might be able to know how the company works and then call up one day and socially engineer important information. This COULD happen and if encryption in general and SSH in particular doesn't immediatly change to prevent this sort of attack, it will happen.
In the old days, crackers went through the garbage of a target, before attacking it. (Hell, that is still done.) Now a days, the word "garbage" means different things. It could be a note to a family member that the boss is out of town for the weekend, that the company is moving to Linux next week or maybe even a Dilbert protype emailing himself his own password to the corporate network. At anyrate, this kind of thing is a bit more serious than it sounds at first glance and should be fixed immediately.
Burn Hollywood Burn
for (i = 0; i < options.number_of_password_prompts; i++) {
if (i != 0)
error("Permission denied, please try again.");
password = read_passphrase(prompt, 0);
packet_start(SSH_CMSG_AUTH_PASSWORD);
ssh_put_password(password);
memset(password, 0, strlen(password));
xfree(password);
packet_send();
packet_write_wait();
type = packet_read(&payload_len);
if (type == SSH_SMSG_SUCCESS)
return 1;
if (type != SSH_SMSG_FAILURE)
packet_disconnect("Protocol error: got %d in response to
passwd auth", type);
}
Many people do not understand this. Some believe they are protecting themselves from this risk via RSA authentication. Of course they're not, because the risk only affects passwords in session:
- gorf: My solution is simply not to use passwords at all; I use RSA keys exclusively...
- SagSaw: The best way I can think of is to use the RSA key authentication method. A RSA key pair is used to authenticate, rather than a password. This way, the password is never typed over the network connection.
- Pinball Wizard: Well, if you use RSA you don't need to type a password so that would solve that particular problem.
- subsolar2: I use RSA authentication for remote access, and have since day one. So the only real worry is somebody getting a copy of my private key...
- Greyfox: As has been noted, RSA is the way to go, at least with SSH authentication...
Others think that a GUI client is more secure entering a password in a dialog box suggests batch processing:- stripes: My Java ssh client happens to have "gotten it right" not because I'm smarter then other ssh client authors but because I had a dialog box to ask for the password.
- Hyperbolix: Teraterm
... has several SSH extensions. I beleive one of them has you type in the password all at once and then sends it as a single string, which means that key timing can't be determined. - rgmoore: I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords.
- garcia: don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
- Rimbo:
...I use the free ttssh extension to the freeware terminal program Tera Term. When it asks you for a password, it captures everything in a dialog box, and sends the password as one chunk.
- Jormundgard: Also, every SSH program I've used in windows takes in the whole password before sending it along.
The very few who got it: