Return-Path: ciac-bulletin@cheetah.llnl.gov 
Delivery-Date: Thu, 03 Feb 1994 20:12:27 -0800
Return-Path: ciac-bulletin@cheetah.llnl.gov
Return-Path: <ciac-bulletin@cheetah.llnl.gov>
Received: from cheetah.llnl.gov by eek. (5.0/SMI-SVR4)
  id AA15179; Thu, 3 Feb 1994 20:12:26 +0800
Received: from cheetah.llnl.gov (localhost.llnl.gov [127.0.0.1]) by cheetah.llnl.gov (8.6.4/8.6.4) with SMTP id UAA17283 for <ciac>; Thu, 3 Feb 1994 20:13:00 -0800
              _____________________________________________________
                          The U.S. Department of Energy
                       Computer Incident Advisory Capability
                              ___  __ __    _     ___
                             /       |     / \   /   
                             \___  __|__  /___\  \___
               _____________________________________________________

                                 ADVISORY NOTICE

                           Network Monitoring Attacks


February 3, 1994 2130 PST                                         Number E-09
______________________________________________________________________________
PROBLEM:   Systematic compromise and exploitation of networked computers to
           capture network transactions.
PLATFORM:  Sun 4.x and Solbourne systems.
DAMAGE:    Unauthorized access and use of resources; exposure of username,
           password, host-name combinations, as well as other sensitive
           information.
SOLUTION:  Detection, prevention, and recovery steps described below.
______________________________________________________________________________

Critical information about the Network Monitoring Attacks

CIAC and other response teams have observed many compromised systems
surreptitiously monitoring network traffic, obtaining username, password,
host-name combinations (and potentially other sensitive information) as
users connect to remote systems using telnet, rlogin, and ftp. This is for
both local and wide area network connections. The intruders may (and
presumably do) use this information to compromise new hosts and expand the
scope of the attacks. Once system administrators discover a compromised
host, they must presume monitoring of all network transactions from or to
any host "visible" on the network for the duration of the compromise, and
that intruders potentially possess any of the information so exposed.

The attacks proceed as follows. The intruders gain unauthorized, privileged
access to a host that supports a network interface capable of monitoring
the network in "promiscuous mode," reading every packet on the network
whether addressed to the host or not. They accomplish this by exploiting
unpatched vulnerabilities or learning a username, password, host-name
combination from the monitoring log of another compromised host. The
intruders then install a network monitoring tool that captures and records
the initial portion of all network traffic for ftp, telnet, and rlogin
sessions. They typically also install "Trojan" programs for login, ps, and
telnetd to support their unauthorized access and other clandestine
activities.

System administrators must begin by determining if intruders have
compromised their systems. The CERT Coordination Center has released a tool
to detect network interface devices in promiscuous mode. Instructions for
obtaining and using the tool appears later in this bulletin--the tool is
available via anonymous ftp. If a site discovers that intruders have
compromised their systems, the site must determine the extent of the attack
and perform recovery as described below. System administrators must also
prevent future attacks as described below.

CIAC advises system administrators to follow the steps described below. The
following guidelines have been extracted (with minor modifications) from
the CERT Coordination Center's Advisory CA-94:01, and full credit is given
to them.

[Beginning of CERT extract.]

     A.  Detection

         The network monitoring tool can be run under a variety of
         process names and log to a variety of filenames.  Thus, the
         best method for detecting the tool is to look for 1) Trojan
         horse programs commonly used in conjunction with this attack,
         2) any suspect processes running on the system, and 3) the
         unauthorized use of /dev/nit.

         1) Trojan horse programs: 

         The intruders have been found to replace one or more of the
         following programs with a Trojan horse version in conjunction
         with this attack:

           /usr/etc/in.telnetd 
           and /bin/login -  Used to provide back-door access for the
                             intruders to retrieve information
           /bin/ps  - Used to disguise the network monitoring process
           
         Because the intruders install Trojan horse variations of
         standard UNIX commands, CERT recommends not using other
         commands such as the standard UNIX sum(1) or cmp(1) commands
         to locate the Trojan horse programs on the system until these
         programs can be restored from distribution media, run from
         read-only media (such as a mounted CD-ROM), or verified using
         cryptographic checksum information.
         
         In addition to the possibility of having the checksum
         programs replaced by the intruders, the Trojan horse programs
         mentioned above may have been engineered to produce the same
         standard checksum and timestamp as the legitimate version.
         Because of this, the standard UNIX sum(1) command and the
         timestamps associated with the programs are not sufficient to
         determine whether the programs have been replaced.

         CERT recommends that you use both the /usr/5bin/sum and
         /bin/sum commands to compare against the distribution media
         and assure that the programs have not been replaced.  The use
         of cmp(1), MD5, Tripwire (only if the baseline checksums were
         created on a distribution system), and other cryptographic
         checksum tools are also sufficient to detect these Trojan
         horse programs, provided these programs were not available
         for modification by the intruder.  If the distribution is
         available on CD-ROM or other read-only device, it may be
         possible to compare against these volumes or run programs off
         these media.

         2) Suspect processes: 

         Although the name of the network monitoring tool can vary
         from attack to attack, it is possible to detect a suspect
         process running as root using ps(1) or other process-listing
         commands.  Until the ps(1) command has been verified against
         distribution media, it should not be relied upon--a Trojan
         horse version is being used by the intruders to hide the
         monitoring process.  Some process names that have been
         observed are sendmail, es, and in.netd.  The arguments to the
         process also provide an indication of where the log file is
         located.  If the "-F" flag is set on the process, the
         filename following indicates the location of the log file
         used for the collection of authentication information for
         later retrieval by the intruders.

         If the network monitoring tool is currently running on your
         system, it is possible to detect this by checking for
         unauthorized use of the /dev/nit interface.  CERT has created
         a minimal tool for this purpose.  The source code for this
         tool is available via anonymous FTP on info.cert.org in the
         /pub/tools/cpm directory or on ftp.uu.net in the 
         /pub/security/cpm directory as cpm.1.0.tar.Z.  The checksum
         information is:

         Filename                Standard UNIX Sum         System V Sum
        --------------           -----------------         ------------
         cpm.1.0.tar.Z:               11097 6                 24453 12 

         MD5 Checksum
         MD5 (cpm.1.0.tar.Z) = e29d43f3a86e647f7ff2aa453329a155

         This archive contains a readme file, also included at the end
         of this extract, containing instructions on installing and
         using this detection tool.

     B.  Prevention

         There are two actions that are effective in preventing this
         attack.  A long-term solution requires eliminating
         transmission of clear-text passwords on the network.  For
         this specific attack, however, a short-term workaround
         exists.  Both of these are described below.

         1) Long-term prevention:

         CERT recognizes that the only effective long-term solution to
         prevent these attacks is by not transmitting reusable
         clear-text passwords on the network.  CERT has collected some
         information on relevant technologies.  This information is
         included as Appendix B in this advisory.  Note: These
         solutions will not protect against transient or remote access
         transmission of clear-text passwords through the network.

         Until everyone connected to your network is using the above
         technologies, your policy should allow only authorized users
         and programs access to promiscuous network interfaces.  The
         tool described in Section III.A.3 above may be helpful in
         verifying this restricted access.

         2) Short-term workaround:

         Regardless of whether the network monitoring software is
         detected on your system, CERT recommends that ALL SITES take
         action to prevent unauthorized network monitoring on their
         systems. You can do this either by removing the interface, if
         it is not used on the system or by attempting to prevent the
         misuse of this interface.

         For systems other than Sun and Solbourne, contact your vendor
         to find out if promiscuous mode network access is supported
         and, if so, what is the recommended method to disable or
         monitor this feature.

         For SunOS 4.x and Solbourne systems, the promiscuous
         interface to the network can be eliminated by removing the
         /dev/nit capability from the kernel.  The procedure for doing
         so is outlined below (see your system manuals for more
         details).  Once the procedure is complete, you may remove the
         device file /dev/nit since it is no longer functional.

         Procedure for removing /dev/nit from the kernel:

         1. Become root on the system. 

         2. Apply "method 1" as outlined in the System and Network
         Administration manual, in the section, "Sun System
         Administration Procedures," Chapter 9, "Reconfiguring the
         System Kernel."  Excerpts from the method are reproduced
         below:

         # cd /usr/kvm/sys/sun[3,3x,4,4c]/conf
         # cp CONFIG_FILE SYS_NAME  

         [Note that at this step, you should replace the CONFIG_FILE
         with your system specific configuration file if one exists.]

         # chmod +w SYS_NAME
         # vi SYS_NAME

            #
            # The following are for streams NIT support.  NIT is used by
            # etherfind, traffic, rarpd, and ndbootd.  As a rule of thumb,
            # NIT is almost always needed on a server and almost never
            # needed on a diskless client.
            #
            pseudo-device   snit            # streams NIT
            pseudo-device   pf              # packet filter
            pseudo-device   nbuf            # NIT buffering module
         
         [Comment out the preceding three lines; save and exit the
         editor before proceeding.]

         # config SYS_NAME
         # cd ../SYS_NAME
         # make

         # mv /vmunix /vmunix.old
         # cp vmunix /vmunix

         # /etc/halt
         > b

         [This step will reboot the system with the new kernel.]

         [NOTE that even after the new kernel is installed, you need
         to take care to ensure that the previous vmunix.old , or
         other kernel, is not used to reboot the system.]


     C.  Scope and recovery

         If you detect the network monitoring software at your site,
         CERT recommends following three steps to successfully
         determine the scope of the problem and to recover from this
         attack.

         1. Restore the system that was subjected to the network
         monitoring software.

         The systems on which the network monitoring and/or Trojan
         horse programs are found have been compromised at the root
         level; your system configuration may have been altered.  See
         Appendix A of this advisory for help with recovery.

         2. Consider changing router, server, and privileged account
         passwords due to the wide-spread nature of these attacks.
         
         Since this threat involves monitoring remote connections,
         take care to change these passwords using some mechanism
         other than remote telnet, rlogin, or FTP access.

         3. Urge users to change passwords on local and remote
         accounts.

         Users who access accounts using telnet, rlogin, or FTP either
         to or from systems within the compromised domain should
         change their passwords after the intruder's network monitor
         has been disabled.
         
         4. Notify remote sites connected from or through the local
         domain of the network compromise.

         Encourage the remote sites to check their systems for
         unauthorized activity.  Be aware that if your site routes
         network traffic between external domains, both of these
         domains may have been compromised by the network monitoring
         software.

---------------------------------------------------------------------------
                         cpm 1.0 README FILE


       cpm -  check for network interfaces in promiscuous mode.

Copyright (c) Carnegie Mellon University 1994
Thursday Feb 3 1994

CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890


   This program is free software; you can distribute it and/or modify
   it as long as you retain the Carnegie Mellon copyright statement.

   It can be obtained via anonymous FTP from info.cert.org:pub/tools/cpm.tar.Z.

   This program is distributed WITHOUT ANY WARRANTY; without the IMPLIED
   WARRANTY of merchantability or fitness for a particular purpose.

   This package contains:
       README
       MANIFEST
       cpm.1
       cpm.c

   To create cpm under SunOS, type:
   % cc -Bstatic -o cpm cpm.c 

   On machines that support dynamic loading, such as Sun's, CERT recommends
   that programs be statically linked so that this feature is disabled.

   CERT recommends that after you install cpm in your favorite directory,
   you take measures to ensure the integrity of the program by noting
   the size and checksums of the source code and resulting binary.


   The following is an example of the output of cpm and its exit status.

   Running cpm on a machine where both the le0 and le2 interfaces are
   in promiscuous mode, under csh(1):

   % cpm
   le0
   le2
   % echo $status
   2
   %

   Running cpm on a machine where no interfaces are in promiscuous 
   mode, under csh(1):

   % cpm
   % echo $status
   0
   %

[End of CERT extract.]
______________________________________________________________________________

CIAC wishes to acknowledge the contributions of the CERT Coordination
Center for their timely and thorough advisory, their detection tool, and
their diligence and support throughout this ongoing incident.
______________________________________________________________________________

For additional information or assistance, please contact CIAC:
    Voice:   (510) 422-8193
    FAX:     (510) 423-8002
    STU-III: (510) 423-2604
    E-mail:  ciac@llnl.gov

Previous CIAC Bulletins and other information are available via anonymous FTP
from irbis.llnl.gov (IP address 128.115.19.60).
______________________________________________________________________________

PLEASE NOTE: Many users outside of the DOE and ESnet computing communities
receive CIAC bulletins.  If you are not part of these communities, please
contact your agency's response team to report incidents.  Your agency's team
will coordinate with CIAC.  The Forum of Incident Response and Security Teams
(FIRST) is a world-wide organization.  A list of FIRST member organizations
and their constituencies can be obtained by sending email to
docserver@first.org with an empty subject line and a message body containing
the line: send first-contacts.

This document was prepared as an account of work sponsored by an agency of the
United States Government.  Neither the United States Government nor the
University of California nor any of their employees, makes any warranty,
expressed or implied, or assumes any legal liability or responsibility for the
accuracy, completeness, or usefulness of any information, product, or process
disclosed, or represents that its use would not infringe privately owned
rights.  Reference herein to any specific commercial products, process, or
service by trade name, trademark manufacturer, or otherwise, does not
necessarily constitute or imply its endorsement, recommendation, or favoring
by the United States Government or the University of California.  The views
and opinions of authors expressed herein do not necessarily state or reflect
those of the United States Government nor the University of California, and
shall not be used for advertising or product endorsement purposes.