ssh and security

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