[2210] in Info-AFS_Redistribution
one-time password logins
daemon@ATHENA.MIT.EDU (Brian Fitzgerald)
Tue Nov 23 15:12:56 1993
To: rpi-mail-afs@usenet.rpi.edu
From: fitzgb@rpi.edu (Brian Fitzgerald)
Date: 23 Nov 1993 17:28:56 GMT
This is just a thought I had:
Even with Kerberos in use, if you connect from one workstation to
another one with, let's say telnet, your password goes out in clear
text over the net.
In light of the PANIX problem (discussed on usenet. A public access
unix user broke root on a machine, collected passwords on /dev/nit, and
vandalized some accounts) I'm wondering whether anyone has considered
implementing something like a public key login system for AFS.
I'm just bringing this up for discussion as an interested individual
user.
Brian
(I'm appending two articles. The first describes the breakins, the
second gives info about "s/key", a public domain one-time password
package.)
--------------------
From alexis@panix.com Sun Nov 7 15:35:58 EST 1993
From: alexis@panix.com (Alexis Rosen)
Newsgroups: comp.security.misc,alt.security,comp.security.unix
Subject: Re: Panix Aftermath - IMPORTANT INFO & SECURITY ALERT
Date: 7 Nov 1993 12:06:55 -0500
Organization: PANIX Public Access Internet and Unix, NYC
Message-ID: <2bj9vf$60q@panix.com>
References: <millar-031193122446@mac02.da.upenn.edu> <1993Nov4.133104.2268@sei.cmu.edu>
NNTP-Posting-Host: panix.com
Keywords: CERT
First of all, my apologies for taking a few days to respond to this. As you
all may imagine, we are still playing catch-up.
Whatever their good qualities, CERT is dealing foolishly with this incident
and I must clarify some important points.
ecd@why.cert.org (Edward DeHart) writes:
>millar@pobox.upenn.edu (David Millar) writes:
>>I still have a few lingering questions about the Panix incident. Can
>>anybody shed any light?
>>
>>Specifically:
>>
>>1. Is this incident limited to panix.com, or are there other sites which
>>had the trojan horse planted on their system?
>This incident was limited to Panix. There have been several simular
>incidents reported to CERT.
NO, THIS INCIDENT WAS NOT LIMITED TO PANIX. In the week following the
incident I got mail from about two dozen admins all stating that they
had been attacked. I now regret the fact that I disposed of much of this
mail; even though I would never have named names, it's possible that I
could have conversed with them and learned more (such as, what kind of
systems and OSes were being run- this was most often not stated). But I
was rather busy at the time...
I want to remind people that in just a couple of days, over 150 sites were
compromised from Panix. This cracking technique is _very_ powerful. Does
anyone really believe that it was used nowhere else? Or only in isolated
locations? Even if I had not gotten any mail, it would be clear to me that
this sort of attack would run like a chain of dominoes across the net.
If CERT has only received "several" such reports, then I suggest that this
says more about how people think (or don't think) of CERT than about how
severe this attack is. (There has already been much discussion of this in
some of these groups. I don't really want to start this again, but it is
clearly an issue here.)
I need to clarify one misconception in the original question: The attack did
not use a Trojan. It used a packet-sniffer using /dev/nit. The key difference
is that many different forms of authentication are compromised (for example,
rlogin and non-anonymous ftp).
/dev/nit is included by default in Sun kernels. We left it in on purpose,
because we felt that we might use it, but have (in light of this attack)
reconsidered. It is now _out_ of our kernel.
SECURITY WARNING:
The fact that /dev/nit is included in the generic kernel led me to strongly
advise CERT that they immediately issue an advisory alerting people to the
danger of leaving /dev/nit in the kernel, and that they take it out unless
they were specifically using it.
The key point is that if your system's root is cracked, that's bad. But if
/dev/nit is available, that's MUCH worse because it makes it easy for the
crackers to compromise _other_ systems. That may, in fact, be the way we
were compromised originally.
(BTW, I refer to /dev/nit here because we use Suns and that is the device
used for raw ethernet access. However, this applies to any system that
supports low-level ethernet access, with whatever device name that system
uses. I don't know if such devices are installed by default on other
systems; my advice is limited to Suns running 4.1.x.)
In addition to alerting people to this potential problem, such an advisory
would also have the salutory effect of reminding people about the general
problem of packet-sniffing on (logically as well as physically) insecure nets.
I don't know why CERT hasn't issued this advisory; I still think that they
should.
>>2. If the answer to 1. is yes, are the attacks limited to any platforms -
>>e.g. was one particular vulnerability exploited, like the recently reported
>>Sun sendmail bug? Are there any hosts I need to look at more carefully
>>than others?
>The problem is not limited to a vendor. If intruders gain access to your
>system, they could replace any or all of the programs that prompt for
>access information. login, su, telnet, and ftp are a few examples.
>The intruders' programs work as expected, however, they also log to a file
>somewhere on your system the information that was collected. Tripwire
>is a good tool for detecting changes in programs. I would suggest checking
>all of the access programs, network daemons and clients, and libraries.
>I would also suggest running Tripwire once a day.
This is all excellent advice. I would suggest, however, that you tripwire
_everything_ not in volatile directories. (This includes, for example, all
your kernel sources or .o files or whatever).
However, you _should_ specifically check for /dev/nit on suns, and get
it out of your kernel if it's there. If a cracker trojans telnet (for
example), tripwire will reveal it. If s/he uses /dev/nit, tripwire won't
help you.
>Intruders have also been known to install packet collection programs. These
>programs collect site names, account names, and passwords. These are
>harder to detect. All traffic passing by the host with the packet collection
>process is available to the intruder.
>If your site allows users to login or use ftp from a remote site, consider
>using one time passwords.
This is also an excellent suggestion. We are modifying some one-time password
source (s/key) for local use.
---
Alexis Rosen Owner/Sysadmin,
PANIX Public Access Unix & Internet, NYC.
alexis@panix.com
-----------------
From jhawk@panix.com Mon Nov 8 22:07:36 EST 1993
From: jhawk@panix.com (John Hawkinson)
Newsgroups: comp.security.misc,alt.security,comp.security.unix
Subject: Re: Panix Aftermath - IMPORTANT INFO & SECURITY ALERT
Date: 8 Nov 1993 21:16:49 -0500
Organization: PANIX Public Access Internet and Unix, NYC
Message-ID: <2bmuih$pas@panix.com>
References: <millar-031193122446@mac02.da.upenn.edu> <1993Nov4.133104.2268@sei.cmu.edu> <2bj9vf$60q@panix.com> <CG543I.64z@news.Hawaii.Edu> <2bk32c$pi9@panix.com> <alastair-081193134626@158.140.32.223>
NNTP-Posting-Host: panix.com
In <alastair-081193134626@158.140.32.223> alastair@cadence.com (Alastair Young) writes:
>> Good questions! Perhaps we can do better than the vendors. S/Key is a great
>> start, and we're doing our little bit to hack in a couple of improvements,
>> which will be posted to the s/key list.
>>
>s/key list? Where do I sign up?
The readme for skey1.1 (ftp from crimelab.com) states:
} S/Key mailing list
} ------------------
}
} We have established a mailing list to be used for S/Key announcements,
} Bug reporting, and for any general discussion of S/Key system.
}
} To get added or deleted from this list, send mail to:
}
} skey-users-request@thumper.bellcore.com
}
} To send to the list, send mail to:
}
} skey-users@thumper.bellcore.com
}
} Please do not send add/delete requests to the entire list.
Since Thor Simon and I have been on the list (the past week
or so), there's been zero traffic. I'll be posting a note to
the list on our experiences with s/key, tonight if I write
any more, otherwise tomorrow. If I receive more than one
e-mail request prior to that, I will post it to alt.security
as well.
For those of you who've missed just what s/key is:
} Description of The S/KEY One-Time Password System
} -------------------------------------------------
}
} The S/KEY one-time password system provides authentication over networks
} that are subject to eavesdropping/reply attacks. This system has several
} advantages compared with other one-time or multi-use authentication
} systems. The user's secret password never crosses the network during
} login, or when executing other commands requiring authentication such as
} the UNIX passwd or su commands. No secret information is stored anywhere,
} including the host being protected, and the underlying algorithm may be
} (and it fact, is) public knowledge. The remote end of this system can run
} on any locally available computer. The host end could be integrated into
} any application requiring authentication.
}
}
} Attributes of the S/KEY One-Time Password System
} ------------------------------------------------
}
} The S/KEY authentication system is a simple scheme that protects user
} passwords against passive attacks. It is not as powerful or general in
} scope as Kerberos or SDASS; nor does it protect against active attacks.
} It can, however, be easily and quickly added to almost any UNIX system
} without requiring any additional hardware and without requiring the
} system to store information (such as plain text passwords) that would
} be more sensitive than the encrypted passwords already stored. The
} S/KEY system can be used with non programmable terminals or personal
} computers (e.g., systems running DOS or Apple Macintoshes) with
} conventional communications programs.
}
} Some of the properties of the S/KEY system are:
}
} o Eavesdropping protection
}
} o Conceptually simple and easy to use
}
} o Based on a memorized secret password; does not require a
} special device although it can easily be adapted to do so.
}
} o Can be automated for authentication from a trusted system.
} (Can also be partially automated for fast operation.)
}
} o No secret algorithms.
}
} o No secrets stored on host.
}
}
}
} Description of the S/KEY One-Time Password System
} -------------------------------------------------
}
} There are two sides to the operation of our one-time password system.
} On the user (or client) side, the appropriate one-time password must
} be generated. On the system (server) side, the one-time password must
} be verified. One time passwords are generated and verified using a
} one-way function based on MD4 [Rivest]. (Conversion to MD5 would be
} trivial)
}
} We have defined our one-way function to take 8 bytes of input and to
} produce 8 bytes of output. This is done by running the 8 bytes of
} input through MD4 and then "folding" pairs of bytes in the 16-byte MD4
} output down to 8 bytes with exclusive-OR operations. This allows us to
} apply the one-way function an arbitrary number of times.
}
}
} Generation of One-Time Passwords
}
} The sequence of one-time passwords is produced by applying the one-way
} function multiple times. That is, the first one-way password is
} produced by running the user's secret password (s) through the one-way
} function some specified number of times, (n). Assuming n=4,
}
} p(1) = f(f(f(f(s))))
}
} The next one-way password is generated by running the user's password
} through the one-way function only n-1 times.
}
} p(2) = f(f(f(s)))
}
} An eavesdropper who has monitored the use of the one-time password
} p(i) will not be able to generate the next one in the sequence p(i+1)
} because doing so would require inverting the one-way function. Without
} knowing the secret key that was the starting point of the function
} iterations, this can not be done.
}
} Seeding the Password
}
} A user might want to use the same secret password on several machines,
} or might allow the iteration count to go to zero. An initial step
} concatenates a seed with the arbitrary length secret password, crunches
} the result with MD4, and folds the result to 64 bits. The result of
} this process is then iterated n times.
}
}
} System Verification of Passwords
}
} The host computer first saves a copy of the one-time password it
} receives, then it applies the one-way function to it. If the result
} does not match the copy stored in the system's password file, then the
} request fails. If they match, then the user's entry in the system
} password file is updated with the copy of the one-time password that
} was saved before the final execution (by the server) of the one-way
} function. This updating advances the password sequence.
}
} Because the number of one-way function iterations executed by the user
} decreases by one each time, at some point the user must reinitialize the
} system or be unable to log in again. This is done by executing a
} special version of the passwd command to start a new sequence of
} one-time passwords. This operation is essentially identical to a
} normal authentication, except that the one-time password receive
} over the network is not checked against the entry already in the
} password file before it replaces it. In this way, the selection of a
} new password can be done safely even in the presence of an eavesdropper.
}
}
} Operation of S/KEY One-Time Password System
} -------------------------------------------
}
} Overview
}
} The S/KEY one-time password authentication system uses computation to
} generate a finite sequence of single-use passwords from a single secret.
} The security is entirely based on a single secret that is known only to
} the user. Alternatively, part of or the entire secret can be stored in a
} non-retrievable way, in the computing device.
}
}
} Generation of S/KEY One-Time Passwords
}
} As mentioned above, the one-time password sequence is derived from the
} secret password using a computer. The required computation has been
} executed on a variety of PC and UNIX class machines including notebook
} and palm-tops. A vendor has estimated that credit card size devices
} could be built for less than $30 in large quantities.
}
} The program can also be stored on and executed from a standard floppy
} disk. This would allow operation on a remote computer that could not be
} entirely trusted not to contain a Trojan Horse that would attempt
} to capture the secret password. It is sometimes useful to pre-compute
} and print several one-time passwords. These could be carried on a trip
} where public terminals or workstations were available, but no trusted
} local computation was available.
}
}
} Description of Operation
}
} The following narrative describes the procedure for logging into a UNIX
} system using the S/KEY one-time password system. To illustrate the
} most complex case, we assume a hand-held PC compatible computer is used.
}
} o The user, call her Sue, identifies herself to the system by login name.
}
} o The system issues a challenge including the sequence number of the
} one-time password expected and a "seed" that is unique to the system.
} This "seed" allows Sue to securely use a single secret for several
} machines. Here the seed is "unix3" and the sequence number is 54.
}
} o Sue enters 54 and unix3 into her palm-top computer. She is prompted
} for her secret password.
}
} o Sue enters her secret password that may be of any length. The palm-top
} computes the 54th one-time password and displays it.
}
} o Sue enters the one-time password and is authenticated.
}
} o Next time Sue wants access, she will be prompted for one-time
} password sequence number 53.
}
}
} Semi-Automated Operation
}
} The complexity illustrated above is necessary only when using a terminal
} that is not programmable by the user, or when using a non-trusted
} terminal. We have built semi-automatic interfaces for clients using
} communications software on popular personal computers. The following
} example illustrates logging in using a trusted personal computer and a
} popular terminal emulation program.
}
} o Before starting the communication program, Sue runs the CTKEY
} program that ties a TSR to a "hot-key" such as F10.
}
} o Sue identifies herself by login name as above.
}
} o The system issues the same challenge including the seed "unix3"
} and the sequence number 54. The host system now expects an
} s/key one-time password.
}
} o Sue presses the hot-key and is then prompted for a secret password
} by the TSR program on the local system.
}
} o In response to Sue's secret password, the 54th one-time password
} is displayed at the position of the cursor.
}
} o Sue presses "Insert" and the terminal emulator transmits the
} one-time password completing the authentication.
}
} If the personal computer were in a trusted location, an option of the
} CTKEY program allows the secret password to be stored in a local file.
}
}
} Form of Password
}
} Internally the one-time password is a 64 bit number. Entering a 64 bit
} number is not a pleasant task. The one-time password is therefore
} converted to a sequence of six short words (1 to 4 letters). Each word
} is chosen from a dictionary of 2048 words. The contents of this
} dictionary is not a secret.
}
}
} Acknowledgments
} ---------------
} The idea behind our system was originally described by Leslie Lamport.
} Some details of the design were contributed by John S. Walden who
} wrote the initial version of the client software.
}
}
} Trademarks
} ----------
} Athena and Kerberos of trademarks of MIT.
} S/KEY is a trademark of Bellcore.
} SPX and DEC are trademarks of Digital Equipment Company.
} UNIX is a registered trademark of UNIX System Laboratories, Inc.
}
}
} References
} ----------
}
} Eugene H. Spafford, "The internet worm program: An analysis." Computer
} Communications Review 19(1):17-57, January 1989.
}
}
} D. C. Feldmeier and P. R. Karn, "UNIX Password Security - Ten Years
} Later", Crypto '89 Conference , Santa Barbara, CA August 20-24, 1989.
}
}
} J. G. Steiner, C. Neuman, and J. I. Schiller. "Kerberos: An
} authentication service for open network systems." USENIX Conference
} Proceedings, pp. 191-202, Dallas, Texas, February 1988.
}
}
} Catherine R. Avril and Ronald L. Orcutt. Athena: MIT's Once and
} Future Distributed Computing Project. Information
} Technology Quarterly , Fall 1990, pp. 4-11.
}
}
} R. L. Rivest, The MD4 Message Digest Algorithm, Crypto '90 Abstracts
} (August 1990), 281-291.
}
}
} Leslie Lamport, "Password Authentication with Insecure Communication",
} Communications of the ACM 24.11 (November 1981), 770-772.
--
John Hawkinson
jhawk@panix.com
