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