Vulnerabilities in the S/KEY one time password system

			[s/key is a trademark of Bellcore]

                                 Author: Mudge
              Organization: L0pht Heavy Industries (aka l0pht.com)
-------------------------------------------------------------------------------
This may be redistributed as long as proper credit is maintained. 
-------------------------------------------------------------------------------
This paper is still under revision and modification. If you have any comments
or feedback please e-mail me.

-------------------------------------------------------------------------------
This text attempts to touch upon several vulnerabilities found in One
Time Password (OTP) implementations such as S/Key. It is organized in the
following manor:

	Introduction
	   brief overview of OTP's and what security issues they
	   attempt to fix.

	Dictionary Attacks
	   brute force OTP hacking

	Spoofing Attacks
	   presenting different iteration counters

	Race Attacks
	   multiple people going in under the same OTP

	Hi-Jacking
	   taking over established OTP sessions

	Outro

-------------------------------------------------------------------------------
				Introduction
-------------------------------------------------------------------------------

Being sniffed is the sys-admins / security analysts 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:

	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:
	[at this point the user either issues the following in another
	 window or else suspends the current session]
	^]
	telnet>^Z
	madwand.l0pht.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
	madwand.l0pht.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 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, when the user escaped to a local shell and
entered the following:

        madwand.l0pht.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 in 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 something like: mary had a little lamb.

The dictionaries used for this sort of attack will simply start to encompass
phrases.

[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 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.



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 (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. 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.

-------------------------------------------------------------------------------

                               Hi-Jacking 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 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.

Along with Hi-jacking, 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.

Don't be lulled into a false sense of security.

-------------------------------------------------------------------------------

                                     Outro

-------------------------------------------------------------------------------

I like s/key. I think s/key is a very usefull 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 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 paper has helped to remind anyone of this then it has done its job.

-Mudge
mudge@l0pht.com