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

complete non-issue

[Ender Ryan]

While entering passwords, simply type with 1 finger, and randomly pause between each keystroke.

But if you need to worry THAT much about security, then I'd assume you have much bigger problems than that to deal with, such as the FBI or CIA or whoever it is going to such great lengths to figure out your password...

keyboard based security

[uigrad_2000]

A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding.

So, take the time to learn Dvorak. You'll save minutes each day in typing, and you're hands will feel better, and it should effectively screw up any timing-based password sniffers!

Quick dvorak "graphic":
' , . p y f g c r l / = \
a o e u i d h t n s -
; q j k x b m w v z

time your password keystrokes

[Grand Facade]

if you use a set pace pausing between each keystroke of password entry, no keystrokes can be discovered!

RickB

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.

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.

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