LWN.net Logo

ssh and security

From:  dlang <dlang-AT-invendra.net>
To:  dlang-AT-invendra.net
Subject:  interesting security article
Date:  Tue, 2 Dec 2003 21:07:53 -0800 (PST)

HTTP://www.asktog.com/columns/058SecurityD'ohlts.html
 
With the Debian server compromise fresh in mind I would like to go on a
minor rant about people's use of ssh.
 
All to frequently people use ssh and consider themselves completely secure
(as an example look at the comments on the latest story of the Debian
server compromise and how people are reacting to the password sniffing
with 'this isn't possible unless there is a hole in ssh')
 
Ssh doesn't not ensure security.
Ssh doesn't even tell you who is connecting to your server.
 
That's right, ssh doesn't tell you who is connecting to your server, it
tells you who the remote machine wants to tell you is connecting to your
server. This is not the same thing.
 
Ssh can do three things.
 
1. Prevent people from sniffing/hijacking the communications session
2. Only allow connections from a machine that knows the secret ssh key
3. Only allow connections from specific IP addresses
 
However the only thing that it does to identify a user is to ask for a
normal password (if it's even configured to do that, frequently people say
that certificates are in use so they don't even need the password). Yes if
the remote host has the secret key configured to require a pass-phrase you
can assume that someone typed that in, but you have no idea if that person
is the person that you intend to grant access to your server to, or if
it's anyone else that has had access to the remote host. Anyone who has
root access on the remote host has the ability to sniff the pass-phrase and
to then use the certificate as that user.
 
No matter what encryption you use the prompt and pass-phrase need to be in
plain text by the time they get to the end-user, if you have access to the
raw keystrokes and screen IO you can capture it (and before you say that
that should be protected as well go read the proposals by Microsoft to try
and do exactly that for their trusted computing stuff, the implications
are scary and you still are vulnerable if there are bugs in the system)
 
The ssh, ssl, and tls algorithms all have ways to 'verify a user' based
on the certificate that they have, but this is only valid if you can trust
the remote machine.
 
Ssh is a valuable tool to use (the importance of preventing the
communications from being intercepted is pretty high) but is is far from
being the solution to all problems.
 
If you really care about who is accessing your systems you need to use
something that isn't vulnerable to a compromised remote host. You can't
prevent a compromised remote host from letting a legitimate user start a
session and then hijacking it, but you can make sure that once that
session is terminated the remote attacker cannot get back in to your
server.
 
In many cases it may be actually safer to user telnet with good user
authentication then to use ssh with poor user authentication.
 
As surprising as this statement is all that it takes to make it true is
for the probability that you are logging in from a compromised host be
higher then the probability that there is a person in the middle waiting to
hijack your session (this is assuming that the actual text of the session
is not valuable so that someone who looks over a transcript of it 5
minutes later doesn't gain anything).
 
How do you do this?
 
It's simple, Challenge-response authentication of some sort.
 
There are a lot of tools out there to do this, but the basic approach is
to have the server send some challenge and the user compute some response
and send it back. The person who has compromised the remote server can
gather this information, but it's useless to them unless the server issues
the same challenge again.
 
This challenge may or may not be explicitly shown to the user.
 
One example would be a one-time password sheet, the user knows to use the
next one on the list and crosses it out, the server doesn't need to say
'use password 63'.
 
Another would be sKey tokens, they have a clock in them that's synced to
the server and have a different password every minute so the 'challenge'
half of this is the time.
 
As one example where there is an explicit challenge there is the snk-004
protocol implemented in software and in hardware tokens sold by passgo in
their defender hand-held token. When using this the server sends a random
number to the user who types it into a token which DES encrypts the
number, displaying it to the use who types it in as the password.
 
Another option that is becoming possible is to use a smart-card to do this
for you so that you can skip the steps of having to type the challenge and
response into equipment. for it to be secure you still have the
challenge-response going on under the covers. In some cases the smart
cards implement certificate authentication which would seem to put them
back in the same risk as the remote servers, but since the smart-card is
not used for anything else the probability of it being compromised is MUCH
lower.
 
Which option you choose to use doesn't matter much (the all have
advantages and disadvantages) the important thing is to use one of them
and to keep the entire security picture in mind as you are doing your
planning.
 
One thing to note is that biometric identification devices (fingerprint
scanners, etc) do not always meet these criteria. If you have an eye
scanner that is just a camera and a bunch of software then this is not
safe as an attacker can capture the output of the camera and feed it back
to the program at a later time when it thinks it's reading from the
camera. you need to have your biometric reader actually participate in the
authentication like a smart card It must also be self-contained. Even
depending on data files on the systems hard drive (to store fingerprints
to compare against for example) puts you at risk because an attacker
could shuffle the files around so that their fingerprint becomes the valid
one for every user.
 
David Lang
 
 


(Log in to post comments)

ssh and security

Posted Dec 4, 2003 16:25 UTC (Thu) by scripter (subscriber, #2654) [Link]

Thank you! I thought your letter was informative, and it makes people aware of the limitations of SSH.

You mention that a challenge response system is a solution to the shortcomings of SSH. Unfortunately, as far as I know, a hardware based challenge-response system is prohibitively expensive, especially in the OSS development model. And it is difficult to distribute the hardware (or a paper with one-time passwords). The hardware costs money. Postage costs money. Administration costs time and/or money. The person issuing the challenge-response system to users has to be able to verify if they want to trust each individual user.

Is there a way to "revoke" a smart card or equivellent system?

Is there a software-only solution that avoids the high distribution costs?

Thoughts?

Can't afford smart cards?

Posted Dec 4, 2003 19:46 UTC (Thu) by kbob (guest, #1770) [Link]

USB smart cards are available for about $40 US. If each developer bought his own, and if each developer could store all his keys on a single card, it would be affordable for the majority of developers. A sponsorship program could provide cards (yes, and postage) to those few who couldn't buy their own.

Then it's an engineering problem of building a web of trust based on smart card authentication.

K<bob>

Can't afford smart cards?

Posted Dec 4, 2003 21:20 UTC (Thu) by dd9jn (subscriber, #4459) [Link]

BTW, we plan to sell the OpenPGP smartcard for about 15 Euro, so you merely need an USB reader (~35 EUR - it should be possible to negotiate discounts). The advantage is that the existing WoT can be used to bootstrap this and the card may also be used for signing and encryption. OpenSC already has experimental support using this card with ssh and gnupg 1.3.4 comes with the card key generation and encryption feature.

-Werner

Can't afford smart cards?

Posted Dec 5, 2003 19:25 UTC (Fri) by atsmyles (guest, #2777) [Link]

Where can I find more information about this product?

ssh and security

Posted Dec 4, 2003 23:57 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

there are packages available to do one-time passwords (OPIE comes to mind, but I'm sure there are others). in addition I have seen several palmpilot packages over the years that implement different options.

personally I use a hardware token I purchased several years ago that does the snk004 protocol. This protocol is implemented in the firewall toolkit so I can throw it on any system I want to protect. I actually have several that I administer where I care more about the authentication then sniffing so I use telnet/ftp with good authentication as opposed to an encrypted connection without the authentication. it's a judgement call that should be made based on the risk in your system.

I would love to be able to tie something like this into ssh and get both, but without hacking the code ssh makes it very hard to do this. the closed source version of ssh has added the ability to ask an external program if a userid and password are correct, but that external program has no way to send a challange to the user so that mechanism can't be used for this type of thing.

One thing I didn't touch on in the letter is that most of these systems do rely on a shared secret so that if one system is comprimised you need to update all the other systems that you access. the new smartcards use public key encryption (and have the ability to hold multiple shared secrets securely) so they will lessen the work to be done when one system gets cracked.

David Lang

ssh and security

Posted Dec 10, 2003 20:23 UTC (Wed) by gswoods (subscriber, #37) [Link]

You can do it with PAM modules. We've got one that uses the TIS FWTK authentication server (free software) with the Axent SNK DES-based tokens (now made by PassGo).

ssh and security

Posted Dec 11, 2003 5:49 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

Thanks, I'll have to look into the details of PAM, I'm useing the FWTK and the defender tokens, but up until very recently I've been useing a non-PAM distro.

ssh and security

Posted Dec 5, 2003 18:24 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

OK, but lets cut to the chase on what change the letter proposes: It does not propose a challenge-response system, because SSH already has that. It proposes to move authentication out to an isolated, hardened system.

The paper with the passwords on it is such a system. It can't do a fraction of what a Linux system can do, and so is much harder to compromise. The smartcard has similar properties. Because it doesn't have the flexibility to do things like run a web server, it's much harder for someone to break into it and steal your keys than it is to break into a Linux system and steal its SSH keys.

ssh and security

Posted Dec 6, 2003 4:20 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]

I am warning that the strength of the authentication that ssh provides is only as good as the security on the remote machine. if it's a strongly protected machine you can say with a fair amount of confidence that the ssh connection really is from the user that you say that it is, if the remote machine is something you have no idea what it's configuration is then you really don't know if the ssh connection comeing from it is really the person it says it is.

as a result the ssh user authentication is not good enough for the use that it is routinly put to.

I'm not saying that both sides of the authentication need to be seperate from ssh, but I am saying that the client side needs to be seperate so that a remote comprimise doesn't grant access.

there was a story a year or so ago about someone who was putting keystroke sniffers on the public access machines at kinkos. this would mean that anyone who used ssh from those machines becomes a direct threat to the servers that they log into.

for opensource project servers with hundreds or thousands of users can you really trust that there isn't SOMEONE in this group that uses ssh from a insecure machine? as soon as someone does then that account could become a stepping stone for an exploit like Debian suffered where a local exploit is essentially the same as a remote exploit.

You are right about the core being the need to move authentication out from the general purpose system, but there is the additional layer of trying to shock people out of their complacency and the growing mindset that ssh == secure

in addition there is a slight hope that if enough people find the argument reasonable that openssh can pickup a modification that will allow this to take place easily ;-)

PDAs and ssh and security

Posted Dec 11, 2003 23:02 UTC (Thu) by eli (guest, #11265) [Link]

As an admittedly partial step in the direction you describe in your letter, you might
consider that many developers have PDAs that could be used in the
challenge-response process. Have a key on the pda and generate the response
from it (and maybe the time). (I'm envisioning the pda displaying it for the user to
enter.)

I store my passwords on my PDA (encrypted with a master password), so this would
be the next logical step. I'd feel a whole lot better with a setup like that for my home
PCs.

Thoughts?

PDAs and ssh and security

Posted Dec 12, 2003 22:47 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

a PDA does a good job of this and can replace a hardware token.

ASSUMING that the contents of the PDA are secured appropriatly.

for example if the application checks your password and then if it matches gives you access to a datafile someone else can get access to the data if you sync it to your desktop.

however if the data on the PDA is encrypted with no encryption key ever stored on the PDA then it's much better

for example if you need to store a 64 bit key on the PDA the best way I've seen is to ask the user for a PIN and then encrypt the key useing that PIN and store the result, when the user needs to access the key have them enter a PIN and use that to decrypt the key, the thing that makes this work is that the key is a random binary blob, an attacker has no way of knowing if it decrypted sucessfully or not, the only way to know is to attempt to use it to access another system. this means that even with a 4 digit PIN it will take an average of 500 login attempts to find that it's right, giveing you a chance to notice (to many bad login protection)

Copyright © 2003, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds