Child pages
  • CERT Incident Note IN-99-04: Attacks Using Various RPC Services

Pages in the Historical section of this site are provided for historical purposes, they are no longer maintained. Links may not work.

Skip to end of metadata
Go to start of metadata
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


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:


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/

    • 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.


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:

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:

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.

Copyright 1999 Carnegie Mellon University.

  • No labels