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 Thursday, July 22, 1999 Overview We have recently received an increasing number of 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: CA-99-08 - Buffer Overflow Vulnerability in rpc.cmsd http://www.cert.org/advisories/CA-99-08-cmsd.html CA-99-05 - Vulnerability in statd exposes vulnerability in automountd http://www.cert.org/advisories/CA-99-05-statd-automountd.html CA-98.11 - Vulnerability in ToolTalk RPC Service http://www.cert.org/advisories/CA-98.11.tooltalk.html Description Recent 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 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. 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. 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: CA-99-08 - Buffer Overflow Vulnerability in rpc.cmsd http://www.cert.org/advisories/CA-99-08-cmsd.html CA-99-05 - Vulnerability in statd exposes vulnerability in automountd http://www.cert.org/advisories/CA-99-05-statd-automountd.html CA-98.11 - Vulnerability in ToolTalk RPC Service http://www.cert.org/advisories/CA-98.11.tooltalk.html 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 personnel answer the hotline 08:00-20: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 http://www.cert.org/CERT_PGP.key. 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 http://www.cert.org/. To be added to our mailing list for advisories and bulletins, send email to cert-advisory-request@cert.org and include SUBSCRIBE your-email-address in the subject of your message. Copyright 1999 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html. * "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.