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?"

Comments

Right...

[Anonymous Coward]

and even more information can be gleaned from looking over someone's back when they type. Let's be serious, guys. ;-)

re: Right...

[Auckerman]

"and even more information can be gleaned from looking over someone's back when they type. Let's be serious, guys. ;-)"

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.

SSH2 and Public Key Authentication

[undie]

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.

Re:SSH2 and Public Key Authentication

[stripes]

That won't quite work; ssh has no idea when you are typing in a password, and when you're expecting an interactive response. Imagine using the passwd command during an ssh session; how does ssh know?

The ssh client doesn't know in general when you are typing a password, but it does know in specific when you are typing the one to start the session. 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. I expect a lot of other window system dependent ssh clients work the same way.

The only problem with this solution, though, is that su-ing can reveal a password.

Or entering passwords for things on the remote host (like things on the serial devices). However the attacker needs to somehow know when you are entering this other password. It won't normally be easy for them to know. Unless they have created a problem, and called you to ask you to fix it... you can type you password locally and paste them into the ssh client, but that seems painful, and it also mean you password is in the local cut buffer which is an attackable location (and also you might paste it somewhere you didn't want to...). Blech.

Re:SSH2 and Public Key Authentication

[stripes]

I'm not sure, but I don't think that the individual characters of the password are sent in separate packets at the start of an ssh session. Feel free to check and correct me :-)

Hmmm, I think you may be right. I don't know enough about the normal SSH code to check, but taking a quick look at mine the password is in a single CMSG_AUTH_PASSWORD packet not the CMSG_STDIN_DATA packets, so I expect everything sends the initial packet as a single chunk. The only thing open to this attack would be passwords sent during a session.

Which means either the authors of the paper took into account the difficulty of guessing what input text is (or might be) the passwords, and we are all in a (modest) bit of trouble, or something fishy is going on here.

So what?

[Reality Master 101]

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.

I have to agree

[Ron Harwood]

The timing of keyboard strokes??? Holy crap - I've just got better things to be worrying about...

Then again, perhaps my typo rate (and requisite back spaces) have helped me all this time.

Defeat the nagle-disabling, and use public keys!

[Kaz Kylheku]

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.

An extreme technique

[jd]

A technique I developed for a company I worked at previously was -reasonably- secure. (NOTE: "Reasonably" is entirely subjective, but being paranoid, I'm fairly sure it isn't too bad.)

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.

Typing

[Swaffs]

"We usually type them in letter-by-letter."

I usually just mash the keyboard with my fist in one shot. Sure, it takes a little longer than normal typing to get the right password, but no one's going to be guessing MY password.

It's traffic analysis, and it isn't just for SSH

[babbage]

The problem isn't really the SSL based tools, so much as the fact that they do a lot to help you but they don't make it impossible to do traffic analysis. The security focus writeup refers to a much longer paper on the subject, and though that paper is specifically about SSH (and password guessing, and guessing at the commands you're entering over a secured session), the authors also note that:

It should be noted that, despite their simplicity, traffic analysis attacks such as those presented in this advisory haven't been well researched. We expect that similar attacks are possible against most other "secure" (encrypted) remote login protocols. We also expect additional traffic analysis attacks on SSH to be discovered. In particular, there may be recognizable patterns in X11 connections forwarded over SSH, but these are out of the scope of this advisory.

So in other words, the strategies they describe here for attacking SSH could be equally effective for most any asynchronous network protocol where you could try to infer information from the rhythm of the rate of data transfer. Further, there is ultimately no general solution, only incremental defenses against the general strategy:

Solving traffic analysis vulnerabilities not related to password information would increase the protocol overhead significantly, and thus doesn't seem practical for many current uses of SSH.

So, as is often the case, if you want perfect security you can only have it at the expense of tremendous overhead, and ultimately you have to decide how far you want to take your defense against chaos theory before deciding that you just have to accept a certain degree of risk. Ultimately, there is no defense and you always have to accept that risk.

SSH public keys

[MSG]

I'm preparing a contribution to policy where I work which includes several stipulations on the use of SSH.

First, password authentication should be disabled, in favor of public key authentication. Second, only encrypted private keys are allowed for login sessions; an ssh agent will be recommened to minimize the inconvenience of repeatedly typing pass phrases. *Long* pass phrases will be recommended. (Note that you can't actually enforce the last two, they're just a matter of procedure.) In cases such as automated scripts which can not use encrypted private keys, a key pair will be generated *for each task*. The public key, when installed, will have the command specified so that the key pair can be used to execute *ONLY* one command.

In addition, all authorized public keys will be kept in a document on an HTTP server. A cron job (python script) will run at least once a day to fetch that list, and compare all of the private keys installed on the system to the authorized list. Any key which isn't in the master list will be removed from the system, and the network admin will be alerted.

Maybe similar procedures would benefit others. Does anyone see holes in this procedure?

Not about login password

[crucini]

This is not about intercepting the ssh login password. It's about interceping passwords entered during an ssh session. Here is the relevant code from sshconnect1.c in OpenSSH:
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:

1. gorf: My solution is simply not to use passwords at all; I use RSA keys exclusively...
2. 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.
3. Pinball Wizard: Well, if you use RSA you don't need to type a password so that would solve that particular problem.
   
4. 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...
   
5. 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:

1. 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.
   
2. 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.
3. rgmoore: I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords.
4. garcia: don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
5. 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.
   
6. 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:

1. Ethan: It's a moot point with SSH anyway, because SSH transmits the password in one chunk as far as I know...
2. Todd Knarr: I think this applies only to passwords typed during an SSH session, not the password during the authentication phase.
3. rtj: There seems to be some confusion as to the nature of this attack on ssh...All ssh implementatons send your password in one packet

I can understand but why?

[Lumpy]

Ok, for a bank or the NSA, I can see needing Nth level encryption and other secret-spy stuff.. bot for joe webmaster or taco logging into the slashnet servers we dont need military grade security. Yes, fixing a hole is a great idea. but we dont need to be running around screaming OMG!!!OMG!!! ssh is insecure!!!! WEll it was insecure when it came out, and it will be forever insecure. you want secure? lock your box in a safe with all drives and ports filled with cement. and not on a network.

That is the only way you can call something secure.

Re:This is a serious attack

[jtdubs]

Here are my problems with what you say:
1) If your passwords are dictionary crackable you have problems even without keytiming sniffing. You can crack a dictionary password using the WHOLE dictionary in less than 10 seconds, why should eliminating 95% of the keyspace be that valuable in this case?

2) If your passwords are not dictionary crackable than the keyspace is HUMONGOUS and eliminating 99% of that keyspace (multiplying by a constant) will leave you with another HUMONGOUS keyspace. Multiplying by constants is never a good way to reduce keyspace size, even if it is .01 (1%).

3) No, one-handed random blindfolded two-finger backwards DVORAK standing-on-your-head typing will NOT help. NO ONE WILL DO IT.

4) No, this is not as horrible as Telnet. A VERY VERY small percentage of people that might be sniffing your network have the skills, motivation and time necessary to analyze your keystroke timing and use that information to any useful extent.

5) Yes, random jitter WOULD be effective. Random jitters don't even come close to averaging out to the real timings unless someone sits there and types there password over and over for several thousand iterations.

Now, for unrelated points of interest:

Anyone that types with any sizeable ammount of speed will not show enough difference in keystroke timings for it to be helpful in any useful way. And I would guess that most people that SSH on a regular basis are pretty good touch typists.

Fine, sending packets at regular intervals, and, more importantly, grouping keystrokes together, is a good solution. However, the situation is not nearly as dire as you would have us believe.

Justin Dubs