287 lines
14 KiB
Plaintext
287 lines
14 KiB
Plaintext
|
|
_
|
|
| \
|
|
| \
|
|
| | \
|
|
__ | |\ \ __
|
|
_____________ _/_/ | | \ \ _/_/ _____________
|
|
| ___________ _/_/ | | \ \ _/_/ ___________ |
|
|
| | _/_/_____ | | > > _/_/_____ | |
|
|
| | /________/ | | / / /________/ | |
|
|
| | | | / / | |
|
|
| | | |/ / | |
|
|
| | | | / | |
|
|
| | | / | |
|
|
| | |_/ | |
|
|
| | | |
|
|
| | c o m m u n i c a t i o n s | |
|
|
| |________________________________________________________________| |
|
|
|____________________________________________________________________|
|
|
|
|
...presents... Vulnerabilities in the S/KEY One-Time
|
|
Password System by Mudge
|
|
01/01/1997-#327
|
|
|
|
__//////\ -cDc- CULT OF THE DEAD COW -cDc- /\\\\\\__
|
|
Est. 1984 \\\\\\/ xXx BOW to the COW xXx \////// Est. 1984
|
|
|
|
__ _ _ __ _ _ __ _ _ __ _ _ __
|
|
|__heal_the_sick__raise_the_dead__cleanse_the_lepers__cast_out_demons__|
|
|
|
|
This text attempts to touch upon several vulnerabilities found in One-
|
|
Time Password (OTP) implementations such as S/KEY. I'm writing specifically
|
|
of the free version of S/KEY from Bellcore.
|
|
|
|
Being sniffed is the sys-admin's/security analyst's worst nightmare
|
|
(well, not really but humor me). For those that aren't aware, 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:
|
|
|
|
evil.guy.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:
|
|
|
|
[At this point the user either issues the following in another window or else
|
|
suspends the current session]
|
|
|
|
^]
|
|
telnet>^Z
|
|
evil.guy.com> key 99 k113356
|
|
Reminder - Do not use key while logged in via telnet or dial-in.
|
|
Enter secret password:[passwd doesn't echo]
|
|
FLY ACE TIDY BURR CON CADY
|
|
evil.guy.com> fg
|
|
Password:FLY ACE TIDY BURR CON CADY
|
|
|
|
Welcome back jdoe!
|
|
bash%
|
|
|
|
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: FLY ACE TIDY BURR CON CADY)
|
|
would not be able to gain access to the machine with this information as the
|
|
same password is not valid for the next session.
|
|
|
|
|
|
* Dictionary Attacks
|
|
|
|
|
|
One of the first vulnerabilities we find 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.
|
|
|
|
Remember in the above example, the user escaped to a local shell and
|
|
entered the following:
|
|
|
|
evil.guy.com> key 99 k113356
|
|
Reminder - Do not use key while loged in via telnet or dial-in.
|
|
Enter secret password:[passwd doesn't echo]
|
|
FLY ACE TIDY BURR CON CADY
|
|
|
|
Since people will pick easy-to-remember words or phrases this works to
|
|
the cracker's advantage. Granted, users can now choose phrases instead of
|
|
a single word... however, how many people are likely to choose "k35jsX/
|
|
O0l3f ffdg99999d" as opposed to "mary had a little lamb"?
|
|
|
|
The dictionaries used for this sort of attack will simply start to
|
|
encompass phrases. For example:
|
|
|
|
username: jdoe # here we have the information
|
|
challenge: 99 k113355 # that we captured
|
|
response: WELD GUY CHIMP SWING GONE
|
|
jdoe's real password: ????
|
|
|
|
dictionary word 1: love # here we start the dictionary
|
|
challenge: 99 k113355 # attack
|
|
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
|
|
S/KEY 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.
|
|
|
|
Another source for dictionary attacks come from the /etc/skeykeys file.
|
|
The number of sites that have S/KEY set up that have the improper permissions
|
|
set on this file is quite surprising (although this is to be expected as the
|
|
code from both Bellcore and Weitse Venema's logdaemon set it up this way. A
|
|
quick fix is to simply change the mode to 600). This file should not be set
|
|
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. The average user 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. He 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
|
|
|
|
|
|
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 sent 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 connection 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.
|
|
|
|
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.
|
|
|
|
|
|
* Race Attacks
|
|
|
|
|
|
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 by (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. As the program has to work this way as to avoid denial of
|
|
service attacks we get the same challenge. When 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 (but wait you say, there can't be a locking problem as S/KEY does
|
|
not do real file locking. Instead it jumps through a bunch of hoops to do a
|
|
similar thing... get the idea?). This should be easily fixable in the source
|
|
but I have not yet investigated this fully.
|
|
|
|
|
|
* Hijacking Attacks
|
|
|
|
|
|
This is not a problem with S/KEY but simply a reminder of your
|
|
vulnerability. 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
|
|
re-check the validity and authorization of a user once he is logged in. It
|
|
is not kerberos. People are too often lulled into a false sense of security,
|
|
as in the choosing of easily guessed passwords, when they use the S/KEY
|
|
system. Once in, the same IP hijacking and monitoring tricks can be used on
|
|
jdoe's session as can be used on non-S/KEY sessions.
|
|
|
|
Along with hijacking, think of the administrator who logs in with his
|
|
OTP and the proceeds to enter new accounts. The passive sniffer will still
|
|
see all of the passwords and sensitive information that the administrator is
|
|
entering.
|
|
|
|
|
|
* Conclusion
|
|
|
|
|
|
I like S/KEY. I think S/KEY is a very useful utility and a great asset
|
|
to the community in general. This article should not dissuade anyone from
|
|
using S/KEY. It is simply meant to point out certain vulnerabilities. The
|
|
worst thing that can happen to the security conscious is thinking they are
|
|
secure when they really aren't. 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 article has helped to remind anyone of this
|
|
then it has done its job.
|
|
|
|
-Mudge mudge@l0pht.com
|
|
Organizations: L0pht Heavy Industries (aka l0pht.com)
|
|
cDc communications
|
|
.-. _ _ .-.
|
|
/ \ .-. ((___)) .-. / \
|
|
/.ooM \ / \ .-. [ x x ] .-. / \ /.ooM \
|
|
-/-------\-------/-----\-----/---\--\ /--/---\-----/-----\-------/-------\-
|
|
/lucky 13\ / \ / `-(' ')-' \ / \ /lucky 13\
|
|
\ / `-' (U) `-' \ /
|
|
`-' the original e-zine `-' _
|
|
Oooo eastside westside / ) __
|
|
/)(\ ( \ WORLDWIDE / ( / \
|
|
\__/ ) / Copyright (c) 1997 cDc communications and the author. \ ) \)(/
|
|
(_/ Award-winning CULT OF THE DEAD COW is a trademark of oooO
|
|
cDc communications, PO Box 53011, Lubbock, TX, 79453, USA. _
|
|
oooO All rights reserved. Edited by Swamp Ratte'. __ ( \
|
|
/ ) /)(\ / \ ) \
|
|
\ ( \__/ Save yourself! Go outside! Do something! \)(/ ( /
|
|
\_) "THE COW WALKS AMONGST US" Oooo
|
|
|