****************************************************************************** ------ ----- ----- --- ----- | ----- ---- | | | | | |--- | | | | | | | | | |-- | | | | |-- | | | | | | | | \ | | ----- ---- ----- ----- | \ ----- A D V I S O R Y FA-98.09 ****************************************************************************** Topic: Attacks involving the rpc.stad vulnerability Source: CERT/CC Creation Date: February 13, 1998 Last Updated: February 13, 1998 To aid in the wide distribution of essential security information, FedCIRC is forwarding the following information from CERT/CC Summary CS-98.01 (Special Edition). FedCIRC urges you to act on this information as soon as possible. If you have any questions, please contact FedCIRC: Telephone: +1 888 282 0870 Email: fedcirc@fedcirc.gov =======================FORWARDED TEXT STARTS HERE============================ -----BEGIN PGP SIGNED MESSAGE----- - --------------------------------------------------------------------------- CERT* Summary CS-98.01 - SPECIAL EDITION February 13, 1998 This special edition of the CERT Summary highlights increasing attacks involving a vulnerability in rpc.statd, also known as statd on some systems. Past CERT Summaries are available from ftp://ftp.cert.org/pub/cert_summaries/ - --------------------------------------------------------------------------- Current activity relating to rpc.statd - -------------------------------------- This special edition of the CERT Summary reports increasing attacks involving a vulnerability in rpc.statd, also known as statd on some systems. A description of this vulnerability and corrective actions can be found in http://www.cert.org/pub/advisories/CA-97.26.statd.html The vulnerability allows a remote attacker to gain root access. WARNING: In some cases, intruders have downloaded and installed a vendor patch designed to fix this vulnerability after they compromise the system. If the patch has been applied on your system, you should verify who installed it. If the patch has been installed and installation was not done by you or another administrator, you may have suffered a root compromise. It appears that intruders are using automated techniques to identify vulnerable systems. On compromised machines, intruders have installed suid root shells, allowing for subsequent root access from non-privileged accounts. In addition, intruders can install Trojan horse versions of utility programs like ps, ls, netstat, or find, making it difficult to detect the intruders' activity. Checking for signs of intrusion - ------------------------------- We encourage sites to check for signs that intruders may have attempted to compromise your machines by exploiting this vulnerability. Sites can do this by examining your firewall or network monitor (such as argus - ftp://ftp.net.cmu.edu/pub/argus-1.5/) logs looking for unexpected connections to port 111, the port normally used by the portmapper or rpcbind. You should also look for connections to the port used by statd which can be found with rpcinfo -p | sed -n -e 1p -e /status/p Note that each time a system is rebooted, the port assigned to statd changes. This means that the port in use when you run the rpcinfo program may be different from the port the intruders used if a machine has been rebooted. You should also examine logs on individual machines. Unusual syslog entries for statd may also indicate an intrusion attempt or an actual compromise. Also, on some older unpatched Sun systems, the rpcbind program may listen on a port different than port 111. We encourage you to correct this condition using the steps outlined in ftp://ftp.cert.org/pub/cert_bulletins/VB-97.03.sun If you discover that your site has been probed for this vulnerability, we encourage you to check your systems for signs of compromise using our Intruder Detection Checklist, available at ftp://ftp.cert.org/pub/tech_tips/intruder_detection_checklist Because an intruder may have installed a patch that corrects this problem, simply checking for the existence of the patch is not enough. This checklist will help you methodically check your systems for signs of compromise. It also includes pointers to other resources and suggestions on how to proceed in the event of a compromise. In many cases, intruders have installed packet sniffers on compromised machines. These sniffers, used to collect account names and passwords, are frequently installed as part of a widely-available toolkit that also replaces common system files with Trojan horse programs. The Trojan horse binaries (du, ls, ifconfig, netstat, login, ps, etc.) hide the intruders' files and sniffer activity on the system on which they are installed. These packet sniffers also frequently hide their logs in system directories such as /usr/include or /dev/ptyxx. For further information and methods for detecting packet sniffers and Trojan horse binaries, see the following files: ftp://ftp.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks ftp://ftp.cert.org/pub/cert_advisories/CA-94:05.MD5.checksums Recovering from a compromise and protecting your system - ------------------------------------------------------- If you discover that you have suffered a root compromise, we encourage you to recover by taking the steps outlined in ftp://ftp.cert.org/pub/tech_tips/root_compromise This document contains information to help you recover from the incident and offers pointers to other resources to help you secure your systems against future compromise. As is good practice with any service, if you do not use NFS you should disable it. If you need to use NFS, you should block NFS traffic at your router or firewall if possible. We recommend a conservative, minimalist approach to network filtering in which only those services specifically required are permitted, while all other services are denied. Scans in addition to the rpc.statd probes - ----------------------------------------- We have continued to see similar scans of the Internet looking for other well-known vulnerabilities, and many of these scans have led to root compromises. Most recently, intruders have launched widespread scans looking for vulnerable IMAP server. For more information, please see ftp://ftp.cert.org/pub/cert_summaries/CS-97.06 ftp://ftp.cert.org/pub/cert_summaries/CS-97.05 ftp://ftp.cert.org/pub/cert_summaries/CS-97.04 ftp://ftp.cert.org/pub/cert_summaries/CS-97.03 ftp://ftp.cert.org/pub/cert_summaries/CS-97.02 In addition, widespread scans looking for other NFS-related vulnerabilities have occurred in the past. For more information, please see ftp://ftp.cert.org/pub/cert_summaries/CS-96.01 Contacting other sites - ---------------------- If, during the course of your investigation, you discover evidence indicating that other sites are involved, we encourage you to contact those sites directly and to include cert@cert.org on the CC line of any messages you exchange. The will help us to better understand the nature, scope, and frequency of security incidents on the Internet, while allowing affected sites to establish direct contact. In addition, we may be able to relate the activity to other activity that has been reported to us. Reporting to your incident response team - ---------------------------------------- If you are represented by another incident response team in the Forum of Incident Response and Security Teams (FIRST), we encourage you to follow up with that team. More information about FIRST can be found at http://www.first.org/ - --------------------------------------------------------------------------- How to Contact the CERT Coordination Center Email cert@cert.org Phone +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30-5:00 p.m. EST (GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax +1 412-268-6989 Postal address CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 USA To be added to our mailing list for CERT advisories and bulletins, send your email address to cert-advisory-request@cert.org In the subject line, type SUBSCRIBE your-email-address CERT advisories and bulletins are posted on the USENET news group comp.security.announce CERT publications, information about FIRST representatives, and other security-related information are available for anonymous FTP from http://www.cert.org/ ftp://ftp.cert.org/pub/ If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise you to encrypt your message. We can support a shared DES key or PGP. Contact the CERT staff for more information. Location of CERT PGP key ftp://ftp.cert.org/pub/CERT_PGP.key - --------------------------------------------------------------------------- Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff . If you do not have FTP or web access, send mail to cert@cert.org with "copyright" in the subject line. * CERT is registered in the U.S. Patent and Trademark Office. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNOScxXVP+x0t4w7BAQH56gQAyr8y0MBrr+Orgxs2m9WbP74bGw/mIeBs H9xeTGBXsP6bRwDODcVu3AdgD0nUgph5I3zW1zNtD5+X/r6j995vtQ3RjcmUpO5n vo8OeEzrOFioZ16XB42AfnCOCO7VE2iFPCyZK28JhXnw4pTiTtvdINCWD7wz67ut QtAlzMr7zXY= =O1Tx -----END PGP SIGNATURE----- ========================FORWARDED TEXT ENDS HERE============================= The National Institute of Standards and Technology (NIST) has established a Federal Computer Incident response Capability (FedCIRC) to assist federal civilians agencies in their incident handling efforts by providing proactive and reactive computer security related services. FedCIRC is a partnership among NIST, the Computer Incident Advisory Capability (CIAC), and the CERT* Coordination Center (CERT/CC). If you believe that your system has been compromised, please contact FedCIRC: Telephone: +1 888 282 0870 Email: fedcirc@fedcirc.gov Web Server: http://www.fedcirc.gov/ * Registered in U.S. Patent and Trademark Office The CERT Coordination Center is part of the Software Engineering Institute. The Software Engineering Institute is sponsored by the U.S. Department of Defense. CIAC, the Computer Incident Advisory Capability, is the computer security incident response team for the U.S. Department of Energy (DOE) and the emergency backup response team for the National Institutes of Health (NIH). CIAC is located at the Lawrence Livermore National Laboratory in Livermore, California. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. 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, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, 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 or the University of California, and shall not be used for advertising or product endorsement purposes.