home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Forum of Incident Response & Security Teams
/
Forum_of_Incident_Response_and_Security_Teams_FIRST_October_1994.iso
/
teaminfo
/
nasirc
/
nasa9402.txt
< prev
next >
Wrap
Text File
|
1994-07-02
|
17KB
|
393 lines
NASIRC BULLETIN #94-02 February 4, 1994
Network Monitoring Vulnerability and System Breakins
===========================================================
__ __ __ ___ ___ ____ ____
/_/\ /_/| /_/ / _/\ /_/| / __/ \ / __/\
| |\ \| || / \ \ | /\/ | || | /\ \/ | | \/
| ||\ \ || / /\ \ \ \ \ | || |_\/ /\ | |
| || \ \|| / /--\ \ \ /\_\\ | || | |\ \ \ | \_/\
|_|/ \_|//_/ \_\/ \/__/ |_|/ |_| \_\/ \___\/
NASA Automated Systems Incident Response Capability
===========================================================
NASIRC has received the following information pertaining to network
monitoring vulnerabilities associated with systems connected to the Internet
or any private TCP/IP network. NASIRC will continue to monitor the situation
and post additional information as it becomes available. The following
guidelines have been extracted (with minor modifications) from the CERT
Coordination Center's Advisory CA-94:01 and CIAC Advisory E-09, and full
credit is given to them.
[Beginning of modified CIAC extract.]
NASIRC and other response teams affiliated with the Forum of Incident
Response and Security Teams (FIRST) 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 their 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 has taken place 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.
NASIRC 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.
[End of modified CIAC extract.]
[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 nasirc.nasa.gov in the
/toolkits/UNIX/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 nasirc.nasa.gov
in directory ~ftp/toolkits/UNIX/cpm/cpm.1.0.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.]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
NASIRC ACKNOWLEDGES: ARPA/CERT and DoE CIAC for their reporting
and coordination of solutions to this problem
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The NASIRC online archive system is available via anonymous ftp.
Just ftp to nasirc.nasa.gov and login as anonymous. You will be
required to enter your valid e-mail address. Once there you can
access the following information:
/toolkits ! contains automated toolkit software
/bulletins ! contains NASIRC bulletins
Information maintained in these directories will be updated on a
continuous basis with relevant software and information. Contact
the NASIRC Helpdesk for more information and assistance with
toolkits or security measures.
===============================================================
For further assistance, please contact the NASIRC Helpdesk:
Phone: 1-800-7-NASIRC Fax: 1-301-441-1853
Internet Email: nasirc@nasa.gov
24 Hour/Emergency Pager: 1-800-759-7243/Pin:2023056
STU III: 1-301-982-5480
===============================================================
This bulletin may be forwarded without restrictions to sites and
system administrators within the NASA community
-----------------
PLEASE NOTE: Users outside of the NASA community may receive NASIRC
bulletins. If you are not part of the NASA community, please contact
your agency's response team to report incidents. Your agency's team
will coordinate with NASIRC, who will ensure the proper internal
NASA team(s) are notified. NASIRC is a member of the Forum of Incident
Response and Security Teams (FIRST), a world-wide organization which
provides for coordination between incident response teams in handling
computer-security-related issues.
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.