300 lines
11 KiB
Plaintext
300 lines
11 KiB
Plaintext
|
|
VULNERABILITIES IN THE S/KEY ONE TIME PASSWORD SYSTEM
|
|
|
|
Author: Mudge
|
|
Organization: L0pht Heavy Industries (aka l0pht.com)
|
|
|
|
_________________________________________________________________
|
|
|
|
This may be redistributed as long as proper credit is maintained. In
|
|
other words... if you like it don't try to take credit for it. If you
|
|
don't like it don't take credit for it.
|
|
_________________________________________________________________
|
|
|
|
This paper is still under revision and modification. If you have any
|
|
comments or feedback please e-mail me.
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
Intro
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
[note: This is not intended to be an extensive introduction on how to
|
|
use the s/key package. For this there are several good resources
|
|
available on the net. What this paper attempts to do is to quickly
|
|
summarize what some of s/key's vulnerabilities are.]
|
|
|
|
Being sniffed is the sys-admin / security specialists worst nightmare.
|
|
For those that aren't privy, sniffing is slang for placing a network
|
|
card into promiscuous mode so that it actually looks at all of the
|
|
traffic coming along the line and not just the packets that are
|
|
addressed to it. By doing this one can catch passwords, login names,
|
|
confidential information, etc. Of course there are good sides to being
|
|
able to place a card into promiscuous mode such as traffic analysis,
|
|
debugging drivers and network applications, and testing router
|
|
configurations to name just a few. In promiscuous mode anything that
|
|
goes by in plaintext is fair game. Each time you telnet to a machine,
|
|
ftp to another machine, connect to the smtp port or POP port, read
|
|
news, off of a different machine, or issue Remote Procedure Calls you
|
|
hand your password and other private information to anyone who wants
|
|
to sit on the lines and listen in. There are several ways of
|
|
protecting oneself. DESLogin provides completely encrypted telnet
|
|
sessions, there is a kerberized POP server available, and there are
|
|
hardware and software utilities to do encryption on different OSI
|
|
layers. Many of these suffer from either being commercial products or
|
|
simply being too difficult to administer.
|
|
|
|
A wonderful security tool was presented to the network community that
|
|
provides a seeming solution to having your password sniffed. The
|
|
theory behind it is to never use the same password. This is
|
|
accomplished by a challenge response system. The system you are
|
|
contacting issues you a unique challenge. You go off and compute your
|
|
response and then send back that unique response to the host. The next
|
|
time you are presented with a different challenge and thus come back
|
|
with a different response. Sounds great doesn't it? What's even better
|
|
is that the software for the server side and the client side are free
|
|
and widely available. Here's an example of what it looks like:
|
|
|
|
|
|
madwand.l0pht.com> telnet some.host.somewhere
|
|
Trying 199.99.99.99... Connected to some.host.somewhere.
|
|
Escape character is '^]'.
|
|
|
|
login: jdoe
|
|
s/key 99 k113355
|
|
Password: WELD GUY CHIMP SWING GONE
|
|
|
|
|
|
|
|
What has happened here is a telnet to a machine where S/KEY is in use.
|
|
After logging in with the username of jdoe, a challenge is issued.
|
|
jdoe computes his response on a local machine and uses that as input
|
|
for the password prompt. Let's take a look at this and figure:
|
|
|
|
|
|
s/key 99 k113355
|
|
s/key - text so the user knows what is going on.
|
|
99 - number of iterations through MD4
|
|
k113355 - seed
|
|
|
|
Assuming jdoe provided a valid response, the next time he would try to
|
|
log in the iterations counter would be decremented [i.e. s/key 98
|
|
k113355] and the response that would be computed would be different.
|
|
Thus anybody who sniffed the above [i.e. user: jdoe - Password: WELD
|
|
GUY CHIMP SWING GONE] would not be able to gain access to the machine
|
|
with this information as the password is no longer valid.
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
Dictionary Attacks
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
A
|
|
|
|
|
|
One of the first vulnerabilities is that all of the information is
|
|
broadcast in plaintext. What this means is that it is trivial to take
|
|
the challenge and response and compare this with the result of the
|
|
challenge applied to words out of a dictionary.
|
|
|
|
|
|
username: jdoe
|
|
challenge: 99 k113355
|
|
response: WELD GUY CHIMP SWING GONE
|
|
jdoe's real password: ????
|
|
|
|
dictionary word 1: love
|
|
challenge: 99 k113355
|
|
response: BAD LOST CRUMB HIDE KNOT
|
|
(well that's not it...)
|
|
|
|
dictionary word 2: sex
|
|
challenge: 99 k113355
|
|
response: FORT HARD BIKE HIT SWING
|
|
(not it either...)
|
|
|
|
dictionary word 3: secret
|
|
challenge 99 k113355
|
|
response: WELD GUY CHIMP SWING GONE
|
|
(bingo! )
|
|
|
|
|
|
|
|
We now know that jdoe's real password is 'secret'. With this
|
|
information we can generate a valid response no matter what the
|
|
challenge.
|
|
|
|
This is particularly important since in the current implementations of
|
|
the skey package neither the client or server side does any sort of
|
|
sanity check on the security of the chosen password. This means there
|
|
is no failsafe to try to prevent you from choosing your login name as
|
|
your password or other silliness.
|
|
|
|
B
|
|
|
|
|
|
Another source for dictionary attacks come from the /etc/skeykeys
|
|
file. The number of sites that have skey set up that have the improper
|
|
permissions set on this file is quite surprising. This file should not
|
|
be set to world readable. While the 'keyinfo' program would like it to
|
|
be so, the harm outweighs the good. The skeykeys file looks like this:
|
|
|
|
|
|
|
|
root 0072 k113357 12afaa8be65f0502 Jun 29,1995 12:40:48
|
|
jdoe 0099 k113355 c7f42dfd84914af3 May 30,1995 16:20:19
|
|
[etc...]
|
|
|
|
|
|
What we have here is the username, iteration counter, seed, and a hex
|
|
representation of the five word response we saw before. The other
|
|
three fields are simply date and time information which isn't of much
|
|
interest right now. The exact same sort of dictionary hack can be made
|
|
with this information. Just to bring the point home, let's pretend you
|
|
have a large user base of say, 200 users, and since you are security
|
|
conscious you have a shadow password system and are using s/key. While
|
|
the average account will not be able to look at the real password file
|
|
since it is shadowed they will not be able to do a standard dictionary
|
|
attack on it. They will, however, be able to see the skeykeys file and
|
|
do a dictionary attack on it if the permissions are set improperly,
|
|
thus defeating the benefits of a shadowed password file.
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
Spoofing Attacks
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
|
|
A
|
|
|
|
|
|
Since the iteration counter is transmitted along with the seed, one
|
|
possibility is to masquerade as the server. This could be done by
|
|
setting up a bogus gateway or whatever. Who we are really spoofing is
|
|
the user. Let's take the following scenario...
|
|
|
|
|
|
login: jdoe
|
|
[jdoe telnet's to his machine]
|
|
|
|
s/key 55 k113355
|
|
password:
|
|
[what jdoe should have seen was a challenge of 98 k113355 but instead we have s
|
|
ent a lower challenge of 55 k113355.]
|
|
|
|
password: MY SPIT LOFT HEAD TEAR
|
|
[jdoe calculates the response for 55 k113355 based upon his secret password]
|
|
|
|
Login incorrect
|
|
login:
|
|
[we tell jdoe that his login was incorrect and forward the rest of the connecti
|
|
on to the actual machine he really wanted to talk to in the first place]
|
|
|
|
|
|
With the response we have for the 55 k113355 challenge all we have to
|
|
do is run it through more iterations of md4 for the subsequent
|
|
responses. For example, with the information we have now, if we want
|
|
to figure out the response for the challenge 60 k113355 we need to run
|
|
it through 5 more iterations of md4. If we were looking for the
|
|
response to the challenge of 97 k113355 we would need to run it
|
|
through 42 more iterations of md4. etc. etc.
|
|
|
|
We can now telnet to the machine and, as long as the iteration counter
|
|
in the challenge is above 55 k113355, we can compute the proper
|
|
response without ever having to know the secret password.
|
|
|
|
There are many variations on the above theme...
|
|
|
|
_________________________________________________________________
|
|
|
|
Trojan Attacks
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
|
|
A
|
|
|
|
|
|
This is not a problem with s/key but simply a reminder.
|
|
|
|
The same vulnerability for trojanized login and su programs for the
|
|
s/key replacements exists as the regulars.
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
Race Attacks
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
|
|
A
|
|
|
|
|
|
There seems to be a problem with s/key that allows two simultaneous
|
|
logins to occur with the same key. If I am in a position to
|
|
capture-look at-modify jdoe's responses as they go bye (i.e. we're a
|
|
bogus gateway or something again), we can open up another telnet
|
|
session to the same machine and, since he hasn't logged in yet the
|
|
iteration counter hasn't been decremented, get the same challenge. As
|
|
we receive jdoe's response we simply send the same information over to
|
|
our other processes as well as his original login. With a little luck
|
|
a locking problem will occur with the skeykeys file and we will both
|
|
be let in under the same challenge and response. This should be easily
|
|
fixable in the source but I have not yet investigated this fully.
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
Hi-Jacking Attacks
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
A
|
|
|
|
|
|
This is not a problem with s/key but simply a reminder.
|
|
|
|
Remember that once a connection has been established and jdoe has
|
|
successfully answered the challenge with the appropriate response
|
|
there are no more checks done on the s/key side of things. It is not
|
|
designed to. It is not kerberos. People are too often lulled into
|
|
false senses of security, as in the choosing of easily guessed
|
|
passwords, when they use the s/key system. Once in, the same IP
|
|
Hi-jacking and monitoring tricks can be used on jdoe's session as can
|
|
be used on non-s/key sessions.
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
Outro
|
|
|
|
|
|
_________________________________________________________________
|
|
|
|
|
|
I like s/key. I think s/key is a very good utility and a great asset
|
|
to the community in general. This paper should not dissuade anyone
|
|
from using s/key. It is simply meant to point out certain
|
|
vulnerabilities. The worst thing that can happen to a the security
|
|
conscious is a false sense of security. While s/key does provide added
|
|
security, neither it nor any other product currently out on the market
|
|
is the be-all end-all to security. If this paper has helped to remind
|
|
anyone of this then it has done it's job.
|
|
|
|
|
|
-Mudge
|
|
mudge@l0pht.com
|