LSTOWN-L Archives

LISTSERV List Owners' Forum

LSTOWN-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Richard Childers <[log in to unmask]>
Sat, 27 Jun 1992 12:57:17 PDT
text/plain (171 lines)
"A few days ago here, I wrote in detail that the Well allows ftp and
 telnet by its users.  That was true a week or so ago.
 
          *** The Well no longer allows ftp and telnet. ***
                 *** It may again in the future. ***
 
"The reasoning for blocking ftp seems to be a fear of "someone ftp'ing
 in a 15Mb file and using up all of the free disk space", according to
 the support people.  They seem to be sort of overly cautious about
 this."
 
This may be germane ... I apologize for not mentioning it earlier.
 
-- richard
 
=====
-- richard childers		[log in to unmask]		1 415 506 2411
         oracle data center  --  unix systems & network administration
 
                   Klein flask for rent. Inquire within.
 
 
 
 
>From [log in to unmask] Mon Jun 22 12:40:45 1992
From: CERT Advisory <[log in to unmask]>
Date: Mon, 22 Jun 92 15:27:42 EDT
To: [log in to unmask]
Subject: CERT Advisory - Altered System Binaries Incident
Organization: Computer Emergency Response Team : 412-268-7090
 
===========================================================================
CA-92:14                        CERT Advisory
                                June 22, 1992
                       Altered System Binaries Incident
 
---------------------------------------------------------------------------
 
The Computer Emergency Response Team/Coordination Center (CERT/CC) has
received information regarding a series of significant intrusion
incidents on the Internet.  Systems administrators should be aware
that many systems on the Internet have been compromised due to this
activity.  To identify whether your systems have been affected by the
activity we recommend that all system administrators check for the
signs of intrusion detailed in this advisory.
 
This advisory describes the activities that have been identified as
part of this particular incident.  This does not address the
possibility that systems may have been compromised due to other,
unrelated intrusion activity.
 
---------------------------------------------------------------------------
 
I.   Description
 
     The intruders gain initial access to a host by discovering a
     password for a user account on the system, exploiting a "+" in
     the "/etc/hosts.equiv" file, or any ".rhosts" files on the
     system.  The intruder then connects to the system using rsh and
     attempts to become root on the compromised system.  An alias of
     "decode" may used to gain root privileges.
 
II.  Impact
 
     Having gained root access on a system, the intruders may make
     unauthorized changes to system binaries that can capture account
     information for both local and remote systems.  In addition, the
     intruder adds "+ +" to any ".rhosts" files to which the intruder
     has access.
 
III. Solution
 
     A. Check your systems for signs of intrusion due to this incident.
 
        1. Check the login, telnet, and uucpd binaries (for example,
           "/bin/login", "/usr/ucb/telnet", and "/usr/etc/in.uucpd" on
           Sun systems) against copies from distribution media.  Note that
           a check for creation or modification times and sizes is
           not sufficient to assure that the files have not been modified.
           The CERT/CC suggests that you compare the output of the
           "sum(1)" or "cmp(1)" command on both the distribution and
           installed versions of the binaries.
 
        2. If the check from (A.1) indicates that your binaries have been
           modified, check for the presence of a password
           log file.  Since the name of the logfile is often changed,
           the name of the file should be obtained using the
           "strings(1)" command on the Trojan login, uucpd, or telnet
           binary.  Examples of filenames used on other systems are:
 
                               "/usr/spool/. " (dot space)
                               "/var/spool/secretmail/.l"
                               "/var/spool/secretmail/.log"
                               "/var/spool/secretmail/.tty"
                               "/var/spool/secretmail/.lock"
                               "/usr/tmp/.log"
                               "/usr/spool/uucp/.sys"
                               "/usr/spool/uucppublic/.hushlogin"
                               "/usr/uucp/.sys"
                               "/mnt2/lost+found/.tmp/.log"
                               "/usr/spool/mqueue/.AFG001"
 
           Verify that the contents of files found using the "strings(1)"
           command do not contain valid username/password combinations.
 
        3. Check for the presence of "+" in the "/etc/hosts.equiv"
           file.
 
           NOTE that Sun Microsystems installs the SunOS
           operating system with a default "+" in the /etc/hosts.equiv
           file for easy network access.  This should be removed
           unless required in your operating environment and protected
           by a firewall network configuration.  Leaving the "+"
           intact will allow any non-root user on the Internet to
           login to the system without a password.
 
        4. Check the home directory for each entry in the "/etc/passwd"
           file for the presence of a ".rhosts" file containing
           "+ +" (plus space plus).
 
        5. Assure that your "/etc/fstab", "/etc/inetd.conf", and
           "/etc/exports" files have not been modified.
 
     B. Take the following steps to secure your systems.
 
        1. Save copies of the identified files to removable media and
           remove any password log files as found in (A.2) above.
 
        2. Replace any modified binaries with copies from
           distribution media.
 
        3. Remove the "+" entry from the "/etc/hosts.equiv"
           file and the "+ +" (plus space plus) entry from any
           ".rhosts" files.
 
        4. Change ownership of the "/etc" directory to userid "root"
           if it is owned by "bin" (as distributed by Sun).
 
        5. Change every password on the system and assure that the new
           passwords are robust using a package such as Crack or Cops
           (available via anonymous ftp from cert.org).
 
        6. Inspect and restore any changes made to your "/etc/fstab",
           "/etc/exports", or "/etc/inetd.conf" files.  If any
           modifications are found in these files, you will need to
           unmount file systems and restart daemons once the files
           have been restored.  Alternatively the system could be
           rebooted.
 
        7. Remove the "decode" alias from your global mail aliases
           file ("/etc/aliases" on Sun systems, "/usr/lib/aliases" on
           other UNIX systems).
---------------------------------------------------------------------------
 
If you believe that your system has been compromised, contact CERT/CC or
your representative in FIRST (Forum of Incident Response and Security Teams).
 
Internet E-mail: [log in to unmask]
Telephone: 412-268-7090 (24-hour hotline)
           CERT/CC personnel answer 7:30 a.m.-6:00 p.m. EST(GMT-5)/EDT(GMT-4),
           on call for emergencies during other hours.
 
Computer Emergency Response Team/Coordination Center (CERT/CC)
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
 
Past advisories, information about FIRST representatives, and other
information related to computer security are available for anonymous ftp
from cert.org (192.88.209.5).

ATOM RSS1 RSS2