CERT® Incident Note IN-99-04
The CERT Coordination Center publishes incident notes to provide
information about incidents to the Internet community.
Similar Attacks Using Various RPC Services
Updated: December 9, 1999 (added information about IN-99-07)
Updated: October 15, 1999 (added information about statd exploit)
Thursday, July 22, 1999
Overview
We have received reports that intruders are using similar methods to
compromise systems. We have seen intruders exploit three different RPC
service vulnerabilities; however, similar artifacts have been found on
compromised systems.
Vulnerabilities we have seen exploited as a part of these attacks
include:
Description
Reports involving these vulnerabilities have involved very similar
intruder activity. The level of activity and the scope of the
incidents suggests that intruders are using scripts to automate
attacks. These attacks appear to attempt multiple exploitations but
produce similar results. We have received reports of the following
types of activity associated with these attacks:
- Core files for rpc.ttdbserverd located in the root "/" directory,
left by an exploitation attempt against rpc.ttdbserverd
- Files named callog.* located in the cmsd spool directory, left
by an exploitation attempt against rpc.cmsd
- Exploitations that execute similar commands to create a privileged
back door into a compromised host. Typically, a second instance of
the inetd daemon is started using an intruder-supplied configuration
file. The configuration file commonly contains an entry that
provides the intruder a privileged back door into the compromised
host. The most common example we have seen looks like this:
/bin/sh -c echo 'ingreslock stream tcp wait root /bin/sh -i' >>
/tmp/bob;/usr/sbin/inetd -s /tmp/bob
If successfully installed and executed, this back door may be used
by an intruder to gain privileged (e.g., root) access to a
compromised host by connecting to the port associated with the
ingreslock service, which is typically TCP port 1524. The
file names and service names are arbitrary; they may be changed to
create an inetd configuration file in a different location or a
back door on a different port.
The /tmp/bob directory has also been evident in exploits against
the statd vulnerability. The most common example we have seen for
statd looks like this:
/var/statmon/sm/; echo "pcserver stream tcp nowait root /bin/sh sh -i" >>
/tmp/bob ; /usr/sbin/inetd -s /tmp/bob
- In many cases, scripts have been used to automate intruder
exploitation of back doors installed on compromised hosts. This
method has been used to install and execute various intruder tools
and tool archives, initiate attacks on other hosts, and collect
output from intruder tools such as packet sniffers.
One common set of intruder tools we have seen is included in an
archive file called neet.tar, which includes several
intruder tools:
- A packet sniffer named update or update.hme that
produces an output file named output or output.hme
- A back door program named doc that is installed as a
replacement to /usr/sbin/inetd. The back door is activated when
a connection is received from a particular source port and a special
string is provided. We have seen the source port of 53982 commonly
used.
- A replacement ps program to hide intruder processes. We have
seen a configuration file installed at /tmp/ps_data on compromised
hosts.
Another common set of intruder tools we have seen is included in an
archive file called leaf.tar, which includes serveral intruder
tools:
- A replacement in.fingerd program with a back door for
intruder access to the compromised host
- eggdrop, an IRC tool commonly installed on compromised
hosts by intruders. In this activity, we've seen the binary
installed as /usr/sbin/nfds
- Various files and scripts associated with eggdrop, many of which
are installed in the directory /usr/lib/rel.so.1
- A replacement root crontab entry used to start eggdrop
It is possible that other tools and tool archives could be
involved in similar activity.
- Installation of distributed denial of service tools. For more
information, see
-
IN-99-07, Distributed Denial of Service Tools
- In some cases, we have seen intruder scripts remove or destroy
system binaries and configuration files.
Solutions
If you believe a host has been compromised, we encourage you to
disconnect the host from the network and review our steps for
recovering from a root compromise:
-
http://www.cert.org/tech_tips/root_compromise.html
In many cases intruders have installed packet sniffers on compromised
hosts and have used scripts to automate collection of the output
logs. It may be the case that usernames and passwords used in network
transactions with a compromised host, or on the same network segment
as a compromised host, may have fallen into intruder hands and are no
longer secure. We encourage you to address password security issues
after any compromised hosts at your site have been secured.
You should also review the state of security on other hosts on your
network. If usernames and passwords have been compromised, an intruder
may be able to gain unauthorized access to other hosts on your
network. Also, an intruder may be able to use trust relationships
between hosts to gain unauthorized access from a compromised host. Our
intruder detection checklist can help you to evaluate a host's state
of security:
-
http://www.cert.org/tech_tips/intruder_detection_checklist.html
We encourage you to ensure that your hosts are current with security
patches or work-arounds for well-known vulnerabilities. In particular,
you may wish to review the following CERT advisories for suggested
solutions:
We also encourage you to regularly review security related patches
released by your vendors.
This document is available from:
http://www.cert.org/incident_notes/IN-99-04.html
CERT/CC Contact Information
Email: cert@cert.org
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
Postal address:
-
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
U.S.A.
CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4)
Monday through Friday; they are on call for emergencies during other
hours, on U.S. holidays, and on weekends.
Using encryption
We strongly urge you to encrypt sensitive information sent by
email. Our public PGP key is available from
If you prefer to use DES, please call the CERT hotline for more
information.
Getting security information
CERT publications and other security information are available from
our web site
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.
NO WARRANTY
Any material furnished by Carnegie Mellon University and the
Software Engineering Institute is furnished on an "as is"
basis. Carnegie Mellon University makes no warranties of any kind,
either expressed or implied as to any matter including, but not
limited to, warranty of fitness for a particular purpose or
merchantability, exclusivity or results obtained from use of the
material. Carnegie Mellon University does not make any warranty of any
kind with respect to freedom from patent, trademark, or copyright
infringement.
Conditions for use, disclaimers, and sponsorship information
Copyright 1999 Carnegie Mellon University.
