************************************************************************** Security Bulletin 9806 DISA Defense Communications System February 17, 1998 Published by: DISN Security Coordination Center (SCC@NIC.MIL) 1-(800) 365-3642 DEFENSE INFORMATION SYSTEM NETWORK SECURITY BULLETIN The DISN SECURITY BULLETIN is distributed by the DISN SCC (Security Coordination Center) under DISA contract as a means of communicating information on network and host security exposures, fixes, and concerns to security and management personnel at DISN facilities. Back issues may be obtained via FTP from NIC.MIL [207.132.116.5] using login= "anonymous" and password="guest". The bulletin pathname is scc/sec-yynn (where "yy" is the year the bulletin is issued and "nn" is a bulletin number, e.g. scc/sec-9705.txt). These are also available at our WWW site, http://nic.mil. ************************************************************************** + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ! ! ! The following important advisory was issued by the Computer ! ! Emergency Response Team (CERT) and is being relayed unedited ! ! via the Defense Information Systems Agency's Security ! ! Coordination Center distribution system as a means of ! ! providing DISN subscribers with useful security information. ! ! ! + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + ============================================================================= -----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----- **************************************************************************** * * * The point of contact for NIPRNET security-related incidents is the * * ASSIST: * * * * E-mail address: ASSIST@ASSIST.MIL * * * * Telephone: 1-(800)-357-4231 (24 hours/day) * * * * You may also contact the Security Coordination Center (SCC) at the * * NIC: * * * * E-mail address: SCC@NIC.MIL * * * * Telephone: 1-(800)-365-3642 * * * * NIC Help Desk personnel are available from 7:00 a.m.-7:00 p.m. EST, * * Monday through Friday except on federal holidays. * * * **************************************************************************** PLEASE NOTE: Some users outside of the DOD computing communities may receive DISN Security Bulletins. If you are not part of the DOD community, please contact your agency's incident response team to report incidents. Your agency's team will coordinate with DOD. The Forum of Incident Response and Security Teams (FIRST) is a world-wide organization. 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. This document was prepared as an service to the DOD community. Neither the United States Government nor any of their employees, makes any warranty, expressed or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, 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. The opinions of the authors expressed herein do not necessarily state or reflect those of the United States Government, and shall not be used for advertising or product endorsement purposes.