CERT® Advisory CA-1989-03 Telnet Breakin Warning
Original issue date: August 16, 1989
Last revised: September 16, 1997
Attached copyright statement
A complete revision history is at the end of this file.
Many computers connected to the Internet have recently experienced
unauthorized system activity. Investigation shows that the activity
has occurred for several months and is spreading. Several UNIX
computers have had their "telnet" programs illicitly replaced with
versions of "telnet" which log outgoing login sessions (including
usernames and passwords to remote systems). It appears that access
has been gained to many of the machines which have appeared in some of
these session logs. (As a first step, frequent telnet users should
change their passwords immediately.) While there is no cause for
panic, there are a number of things that system administrators can do
to detect whether the security on their machines has been compromised
using this approach and to tighten security on their systems where
necessary. At a minimum, all UNIX site administrators should do the
- Test telnet for unauthorized changes by using the UNIX "strings"
command to search for path/filenames of possible log files. Affected
sites have noticed that their telnet programs were logging information
in user accounts under directory names such as "..." and ".mail".
In general, we suggest that site administrators be attentive to
configuration management issues. These include the following:
- Test authenticity of critical programs - Any program with access to
the network (e.g., the TCP/IP suite) or with access to usernames and
passwords should be periodically tested for unauthorized changes.
Such a test can be done by comparing checksums of on-line copies of
these programs to checksums of original copies. (Checksums can be
calculated with the UNIX "sum" command.) Alternatively, these
programs can be periodically reloaded from original tapes.
Privileged programs - Programs that grant privileges to users (e.g.,
setuid root programs/shells in UNIX) can be exploited to gain
unrestricted access to systems. System administrators should watch
for such programs being placed in places such as /tmp and /usr/tmp (on
UNIX systems). A common malicious practice is to place a setuid shell
(sh or csh) in the /tmp directory, thus creating a "back door" whereby
any user can gain privileged system access.
Monitor system logs - System access logs should be periodically
scanned (e.g., via UNIX "last" command) for suspicious or unlikely
Terminal servers - Terminal servers with unrestricted network access
(that is, terminal servers which allow users to connect to and from
any system on the Internet) are frequently used to camouflage network
connections, making it difficult to track unauthorized activity.
Most popular terminal servers can be configured to restrict network
access to and from local hosts.
Passwords - Guest accounts and accounts with trivial passwords
(e.g., username=password, password=none) are common targets. System
administrators should make sure that all accounts are password
protected and encourage users to use acceptable passwords as well as
to change their passwords periodically, as a general practice. For
more information on passwords, see Federal Information Processing
Standard Publication (FIPS PUB) 112, available from the National
Technical Information Service, U.S. Department of Commerce,
Springfield, VA 22161.
Anonymous file transfer - Unrestricted file transfer access to a
system can be exploited to obtain sensitive files such as the UNIX
/etc/passwd file. If used, TFTP (Trivial File Transfer Protocol -
which requires no username/password authentication) should always be
configured to run as a non-privileged user and "chroot" to a file
structure where the remote user cannot transfer the system /etc/passwd
file. Anonymous FTP, too, should not allow the remote user to access
this file, or any other critical system file. Configuring these
facilities to "chroot" limits file access to a localized directory
Apply fixes - Many of the old "holes" in UNIX have been closed.
Check with your vendor and install all of the latest fixes.
If system administrators do discover any unauthorized system activity,
they are urged to contact the Computer Emergency Response Team (CERT).
This document is available from:
CERT/CC Contact Information
Phone: +1 412-268-7090 (24-hour hotline)
Fax: +1 412-268-6989
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
CERT/CC personnel answer the hotline 08:00-17: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.
We strongly urge you to encrypt sensitive information sent by
email. Our public PGP key is available from
If you prefer to use DES, please call the CERT hotline for more
Getting security information
CERT publications and other security information are available from
our web site
* "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office.
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
Conditions for use, disclaimers, and sponsorship information
Copyright 1989 Carnegie Mellon University.
September 16,1997 Attached copyright statement