Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!
tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!krvw
From: k...@sei.cmu.edu (Kenneth Van Wyk)
Newsgroups: comp.unix.wizards
Subject: CERT Internet Security Advisory
Message-ID: <3855@fy.sei.cmu.edu>
Date: 16 Aug 89 15:56:09 GMT
Organization: Carnegie-Mellon University (Software Engineering Institute),
Pgh, PA
Lines: 85
Many computers connected to the Internet have recently experienced
unauthorized system activity. Investigation shows that the activity
has occurred for several months and is spreading. Several UNIX
computers have had their "telnet" programs illicitly replaced with
versions of "telnet" which log outgoing login sessions (including
usernames and passwords to remote systems). It appears that access
has been gained to many of the machines which have appeared in some of
these session logs. (As a first step, frequent telnet users should
change their passwords immediately.) While there is no cause for
panic, there are a number of things that system administrators can do
to detect whether the security on their machines has been compromised
using this approach and to tighten security on their systems where
necessary. At a minimum, all UNIX site administrators should do the
following:
o Test telnet for unauthorized changes by using the UNIX "strings"
command to search for path/filenames of possible log files. Affected
sites have noticed that their telnet programs were logging information
in user accounts under directory names such as "..." and ".mail".
In general, we suggest that site administrators be attentive to
configuration management issues. These include the following:
o Test authenticity of critical programs - Any program with access to
the network (e.g., the TCP/IP suite) or with access to usernames and
passwords should be periodically tested for unauthorized changes.
Such a test can be done by comparing checksums of on-line copies of
these programs to checksums of original copies. (Checksums can be
calculated with the UNIX "sum" command.) Alternatively, these
programs can be periodically reloaded from original tapes.
o Privileged programs - Programs that grant privileges to users (e.g.,
setuid root programs/shells in UNIX) can be exploited to gain
unrestricted access to systems. System administrators should watch
for such programs being placed in places such as /tmp and /usr/tmp (on
UNIX systems). A common malicious practice is to place a setuid shell
(sh or csh) in the /tmp directory, thus creating a "back door" whereby
any user can gain privileged system access.
o Monitor system logs - System access logs should be periodically
scanned (e.g., via UNIX "last" command) for suspicious or unlikely
system activity.
o Terminal servers - Terminal servers with unrestricted network access
(that is, terminal servers which allow users to connect to and from
any system on the Internet) are frequently used to camouflage network
connections, making it difficult to track unauthorized activity.
Most popular terminal servers can be configured to restrict network
access to and from local hosts.
o Passwords - Guest accounts and accounts with trivial passwords
(e.g., username=password, password=none) are common targets. System
administrators should make sure that all accounts are password
protected and encourage users to use acceptable passwords as well as
to change their passwords periodically, as a general practice. For
more information on passwords, see Federal Information Processing
Standard Publication (FIPS PUB) 112, available from the National
Technical Information Service, U.S. Department of Commerce,
Springfield, VA 22161.
o Anonymous file transfer - Unrestricted file transfer access to a
system can be exploited to obtain sensitive files such as the UNIX
/etc/passwd file. If used, TFTP (Trivial File Transfer Protocol -
which requires no username/password authentication) should always be
configured to run as a non-privileged user and "chroot" to a file
structure where the remote user cannot transfer the system /etc/passwd
file. Anonymous FTP, too, should not allow the remote user to access
this file, or any other critical system file. Configuring these
facilities to "chroot" limits file access to a localized directory
structure.
o Apply fixes - Many of the old "holes" in UNIX have been closed.
Check with your vendor and install all of the latest fixes.
If system administrators do discover any unauthorized system activity,
they are urged to contact the Computer Emergency Response Team (CERT).
Kenneth R. van Wyk
Computer Emergency Response Team
c...@SEI.CMU.EDU
(412) 268-7090 (24 hour hotline)
Path: utzoo!attcan!utgpu!watmath!iuvax!mailrus!accuvax.nwu.edu!
delta.eecs.nwu.edu!phil
From: p...@delta.eecs.nwu.edu (William LeFebvre)
Newsgroups: comp.unix.wizards
Subject: Re: Unix network security (was "CERT Internet Security Advisory")
Message-ID: <1064@accuvax.nwu.edu>
Date: 17 Aug 89 15:50:56 GMT
References: <3855@fy.sei.cmu.edu>
Reply-To: p...@delta.eecs.nwu.edu (William LeFebvre)
Organization: Northwestern U, Evanston IL, USA
Lines: 52
Now that the CERT has made the problem known, I can put forth an idea
that might help prevent similar "breaches" in the future....
I have an idea for protecting Internet sites from breakins such as the
one that was at the root of the problem just described by CERT. I
have had this idea for quite some time, and I really can't see
anything seriously wrong with it.
When /bin/login knows it is processing a remote login, why can't it
check the hostname against a list of "allowed" hosts? If the host is
not in the list, make the login fail in the usual way (encrypt the
password and fail the login) no matter *what* the password is. Each
user can have his/her own list of "allowed" hosts, just like we do
with ".rhosts". This file could contain not only host names, but also
a limited form of wildcarding, such as "*.nwu.edu" (which would allow
any host in the "nwu.edu" domain).
What this prevents: random user from random Internet site repeatedly
trying different passwords to try to log into an account over the net.
As I understand it, the person in this most recent rash of invasions
would first find a username (very easy to do) and try obvious
passwords for that name. Login's 60 second limit is pretty much
unimportant on the Internet: just type "!!" and keep trying (my
apologies to "sh" users). Since this is done by /bin/login, ALL forms
of network access are limited, be they rlogin, telnet, or whathaveyou.
How this interferes: as a legitimate user, you can't log in from just
anywhere. But how often does that happen? How often do you sit down
at a random Internet site and log in to your primary computer? If you
know you are about to make a trip to some other location, then plan
ahead and put that location's domain in the list of allowed hosts
before you leave. But just in case there are some people who really
need the current openness, there should probably be a way for an
individual user to disable the checking for his/her account, such as
adding the line "*" to the list of allowed hosts.
Let's face it: for 99% of the Internet hosts, you don't want a remote
login from that host into your account to succeed. So why not have a
mechanism in place for disallowing them? As a concerned sysadmin and
user, I certainly want this kind of protection for my own account, and
especially for my "root" account!
And it's not like this is all that hard to do......
What think you all?
William LeFebvre
Department of Electrical Engineering and Computer Science
Northwestern University
<p...@eecs.nwu.edu>
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!network!ucsd!rutgers!phri!roy
From: r...@phri.UUCP (Roy Smith)
Newsgroups: comp.unix.wizards
Subject: Re: Unix network security (was "CERT Internet Security Advisory")
Message-ID: <3942@phri.UUCP>
Date: 17 Aug 89 23:34:00 GMT
References: <3855@fy.sei.cmu.edu> <1064@accuvax.nwu.edu>
Reply-To: r...@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 22
In <1...@accuvax.nwu.edu> p...@delta.eecs.nwu.edu (William LeFebvre) writes:
> When /bin/login knows it is processing a remote login, why can't it
> check the hostname against a list of "allowed" hosts?
I can't find any problems with William's suggestion, but would add
one more idea. Before allowing a shot at a username/password, require a
network access password. The same thing could be done for dial-up access,
but this is less of a problem. This password would be picked by the system
administrator, (theoretically) ensuring that it wasn't an obvious one, like
lusers tend to pick. This is not a new idea, but seems to be implemented
only in very security concious sites; perhaps it should be the default way
vendors ship their systems. Multiple failures to get the network access
password right should be logged in the system security log.
Actually, I can find one problem with William's suggestion. Just
like people tend to pick poor passwords, I suspect many people would put
"*" in their .netaccess files, effectively defeating the whole idea.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- r...@alanine.phri.nyu.edu
"The connector is the network"
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!
cs.utexas.edu!usc!ginosko!xanth!mcnc!decvax!testmax.ZK3.DEC.COM!evans
From: ev...@testmax.ZK3.DEC.COM (Marc Evans Ultrix Q/A)
Newsgroups: comp.unix.wizards
Subject: Re: Unix network security (was "CERT Internet Security Advisory")
Message-ID: <5491@decvax.dec.com>
Date: 18 Aug 89 11:34:48 GMT
References: <3942@phri.UUCP> <3855@fy.sei.cmu.edu> <1064@accuvax.nwu.edu>
Sender: n...@decvax.dec.com
Lines: 19
Re: Unix network security (was "CERT Interne r...@phri.UUCP
> check the hostname against a list of "allowed" hosts?
Chances are that if I were smart enough to modify something like telnet to
trace lognames/passwords, it wouldn't be too hard for me to also know what
the hostnames are, that were communicating. I could also probably know the
internet address and maybe even the hardware address. Assuming that I can
get this information, then it probably isn't too hard for me to set up my
host to mimic the environment used by the authorized user(s).
I am not trying to say that the idea isn't a bad one. It would probably
make it more difficult for people to gain unauthorized access. What I am
saying is that you will probably never remove all possible access means
as long as machines are networked together, and people have access to
either the console or the super users account at some point in time.
==========================================================================
Marc Evans - WB1GRH - ev...@decvax.DEC.COM | Synergytics (603)893-8481
Unix/X-window Software Contractor | 3 Koper Ln, Pelham, NH 03076
==========================================================================
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!ctrsol!sdsu!usc!
apple!spies!zorch!scott
From: sc...@zorch.SF-Bay.ORG (Scott Hazen Mueller)
Newsgroups: comp.unix.wizards
Subject: Re: Unix network security
Message-ID: <823@zorch.SF-Bay.ORG>
Date: 18 Aug 89 16:12:17 GMT
References: <3855@fy.sei.cmu.edu> <1064@accuvax.nwu.edu> <3942@phri.UUCP>
Reply-To: sc...@zorch.SF-Bay.ORG (Scott Hazen Mueller)
Organization: SF Bay Public-Access Unix
Lines: 17
In article <3...@phri.UUCP> r...@phri.UUCP (Roy Smith) writes:
>Before allowing a shot at a username/password, require a network access
>password. The same thing could be done for dial-up access, but this is
>less of a problem.
I know that this would pull "features" from both BSD and SysV, but I think
that it would be trivial to do. If I understand things right, an incoming
remote login (rlogin, telnet) is associated with one of a set of ttyp/pty
devices. System V provides a "dialup password" facility that could provide
the protection mechanism that Roy suggests, simply by specifying all of
the pseudo-terminals in /etc/dialups and putting the appropriate shell
entries in /etc/d_passwd. To see if your version of /bin/login has these
features, simply use strings and grep to look for the filenames.
--
Scott Hazen Mueller| sc...@zorch.SF-Bay.ORG (ames|pyramid|vsi1)!zorch!scott
685 Balfour Drive | (408) 298-6213 |Mail to fusion-requ...@zorch.SF-Bay.ORG
San Jose, CA 95111 |No room for quote.|for sci.physics.fusion digests via email
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!
execu!sequoia!rpp386!jfh
From: j...@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: Unix network security
Message-ID: <16918@rpp386.Dallas.TX.US>
Date: 19 Aug 89 21:52:10 GMT
References: <3855@fy.sei.cmu.edu> <1064@accuvax.nwu.edu> <3942@phri.UUCP>
<823@zorch.SF-Bay.ORG>
Reply-To: j...@rpp386.cactus.org (John F. Haugh II)
Organization: I am NOT the NRA
Lines: 22
In article <8...@zorch.SF-Bay.ORG> sc...@zorch.SF-Bay.ORG (Scott Hazen Mueller)
writes:
>I know that this would pull "features" from both BSD and SysV, but I think
>that it would be trivial to do. If I understand things right, an incoming
>remote login (rlogin, telnet) is associated with one of a set of ttyp/pty
>devices. System V provides a "dialup password" facility that could provide
>the protection mechanism that Roy suggests, simply by specifying all of
>the pseudo-terminals in /etc/dialups and putting the appropriate shell
>entries in /etc/d_passwd. To see if your version of /bin/login has these
>features, simply use strings and grep to look for the filenames.
The dialup feature is old enough that it should be present in the bowels
of BSD login.
At any rate, the login I wrote last year should be adaptable [ hear that
Dave? ] to BSD with little effort and it has dialups and every other known
feature, useful or not ;-). Look under 'shadow2' or something like that
in the comp.sources.misc archives near you.
--
John F. Haugh II +-Quote of the month club: ------------
VoiceNet: (512) 832-8832 Data: -8835 | "Chocolate Teddy Grahams are just
InterNet: j...@rpp386.cactus.org | reincarnated Space Food Sticks."
UUCPNet: {texbell|bigtex}!rpp386!jfh +------------ -- Richard Sexton ---
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!
gem.mps.ohio-state.edu!ginosko!uunet!auspex!guy
From: g...@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Unix network security
Message-ID: <2376@auspex.auspex.com>
Date: 21 Aug 89 18:09:10 GMT
References: <3855@fy.sei.cmu.edu> <1064@accuvax.nwu.edu> <3942@phri.UUCP>
<823@zorch.SF-Bay.ORG> <16918@rpp386.Dallas.TX.US>
Reply-To: g...@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 5
>The dialup feature is old enough that it should be present in the bowels
>of BSD login.
No, it's not. It doesn't date back to V7, and the BSD "login" is based
on the V7 one. The BSD "login" does not have a dialup password feature.