Author: CERT(sm) Coordination Center
Date: January 1996
HTML-Version: Markus Hübner
The information in this document can help you:
Section A lists several ways to determine whether or not your system has been compromised. Sections B and C contain lists of UNIX and VMS system vulnerabilities that have been exploited by intruders to gain unauthorized access to systems. Section D includes descriptions of tools that can be used to help secure a system.
System administrators can use this document to prevent several types of break-ins. We encourage system administrators to review all sections of this document and modify their systems accordingly to close these potential vulnerabilities.
In addition to the information in this document, we provide an 01-README file, which contains a list and brief description of all CERT advisories. This file is available by anonymous FTP from
ftp://info.cert.org/pub/cert_advisories/01-README
We encourage you to get all advisories that pertain to your system(s), along with the widely applicable advisories, such as those on rdist and TFTP, and to install all patches or workarounds described in the advisories.
find / -user root -perm -4000 -print
Some find(1) commands support an "-xdev" option to avoid searching those hierarchies.
Another way to search for setuid files is to use the ncheck(8) command on each disk partition. For example, use the following command to search for setuid files and special devices on the disk partition /dev/rsd0g:
ncheck -s /dev/rsd0g
Trojan horse programs may produce the same standard checksum and timestamp as the legitimate version. Because of this, the standard UNIX sum(1) command and the timestamps associated with the programs are not sufficient to determine whether the programs have been replaced.
The use of cmp(1), MD5, and other cryptographic checksum tools is sufficient to detect these Trojan horse programs, provided the checksum tools were not available for modification by the intruder.
Intruders often use finger or ruser to discover account names and then try simple passwords. Encourage your users to choose passwords that are difficult to guess (for example, words that are not in any dictionary of words of any language; no proper nouns, including names of "famous" real or fictitious characters; no acronyms that are common to computer professionals; no simple variations of first or last names.) Furthermore, inform your users not to leave any clear-text username/password information in files on any system.
A good heuristic for choosing a password is to choose an easy-to-remember phrase, such as "By The Dawn's Early Light", and use the first letters to form a password. Add some punctuation or mix case letters as well. For the phrase above, one example password might be: bt}DeL{. (DO NOT use this sample phrase for your password.)
If intruders can get a password file, they usually move or copy it to another machine and run password guessing programs on it. These programs involve large dictionary searches and run quickly even on slow machines. Most systems that do not put any controls on the types of passwords used probably have at least one password that can be easily guessed.
If you believe that your password file may have been taken, change all the passwords on the system. At the very least, you should change all system passwords because an intruder may concentrate on those and may be able to guess even a reasonably 'good' password.
Section D contains a list of tools, some of which can help you to to ensure that users set 'good' passwords and that encrypted passwords are not visible to system users.
Intruders exploit system default passwords that have not been changed since installation,including accounts with vendor-supplied default passwords. Be sure to change all default passwords when the software is installed. Also, be aware that product upgrades can quietly change account passwords to a new default. It is best to change the passwords of default accounts after applying updates.
Scan your password file for extra UID 0 accounts, accounts with no password, or new entries in the password file. Do not allow any accounts without passwords. Remove entries for unused accounts from the password file. To disable an account, change the password field in the /etc/passwd file to an asterisk '*' and change the login shell to /bin/false to ensure that an intruder cannot login to the account from a trusted system on the network.
Even when excellent passwords are chosen, if these passwords are sent in clear text across public networks, they are subject to capture by sniffer programs. We recommend moving to one-time passwords, especially for authenticated accesses from external networks, and for accesses to sensitive resources like name servers and routers. For more information, see the appendix of the following advisory:
ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
To test your system for this vulnerability, connect to your system using tftp and try
get /etc/motd
If you can do this, anyone else on the network can probably get your password file. To avoid this problem, either disable tftpd if you don't require it or ensure that it is configured with restricted access.
If you believe your password file may have been taken, the safest course is to change all passwords in the system.
There have been a number vulnerabilities identified over the years in sendmail(8). To the best of our knowledge, BSD 8.6.9 appears to address those vulnerabilities. To establish which version of sendmail are running, use telnet to connect to the SMTP port (25) on your system:
telnet25
We encourage you to keep up to date with the latest version of sendmail from your vendor, and ensure that it is up to date with any security patches or workarounds detailed in CERT advisories and bulletins. See also the Sendmail Bug list.
Make sure that you are running the most recent version of ftpd. Check with your vendor for information on configuration upgrades. Also check your anonymous FTP configuration. It is important to follow the instructions provided with the operating system to properly configure the files and directories available through anonymous FTP (for example, file and directory permissions, ownership and group). Note that you should not use your system's standard password file or group file as the password file or group file for FTP. The anonymous FTP root directory and its two subdirectories, etc and bin, should not be owned by ftp. For more information, see
ftp://info.cert.org/pub/tech_tips/anonymous_ftp
Several vendors supply /etc/hosts.equiv files with a '+' (plus sign) entry. The '+' entry should be removed from this file because it means that your system will trust all other systems. Other files that should not contain a '+' entry include /etc/hosts.lpd and all .rhosts files on the system. These files should not be world-writable.
If your /usr/lib/X11/xdm/Xsession file includes the line
/usr/bin/X11/xhost +
remove that line. If this line remains intact, anyone on the network can talk to the X server and potentially stuff commands into windows or read console keystrokes.
If your machine supports uucp, check the L.cmds (Permissions) file and ensure that only the commands you require are included. This file should be owned by root (not by uucp!) and should be world-readable. The L.sys (Systems) file should be owned by uucp and protected (600) so that only programs running setuid uucp can access it.
Check the file /etc/ttys or /etc/ttytab depending on the release of UNIX being used. The default setting should be that no terminal lines, pseudo terminals, or network terminals are set secure except for the console.
Examine the /usr/lib/aliases (mail alias) file for inappropriate entries. Some alias files include an alias named 'uudecode' or just 'decode'. If this alias exists on your system and you are not explicitly using it, then it should be removed.
Check your system documentation to establish the correct file and directory protections and ownership for system files and directories. In particular, check the '/' (root) and '/etc' directories, and all system and network configuration files. Examine file and directory protections before and after installing software or running verification utilities. These procedures can cause file and directory protections to change.
Older versions of operating systems often have security vulnerabilities that are well known to intruders. To minimize your vulnerability to attacks, keep the version of your operating system up to date and apply security patches appropriate to your system(s) as soon as they become available.
Setuid shell scripts (especially setuid root) can pose potential security problems, a fact that has been well documented in many UNIX system administration texts. Do not create or allow setuid shell scripts, especially setuid root.
Wherever possible, file systems should be exported read-only. Check the configuration of the /etc/exports files on your hosts. Do not self-reference an NFS server in its own exports file. Do not allow the exports file to contain a "localhost" entry. Export file systems only to hosts that require them. Export only to fully qualified hostnames. Ensure that export lists do not exceed 256 characters after the aliases have been expanded or that all security patches relating to this problem have been applied. Use the showmount(8) utility to check that exports are correct.
Intruders often exploit system default passwords that have not been changed since installation. Be sure to change all default passwords when the software is installed. Be aware that product upgrades can quietly change account passwords to a new default. It is best to change the passwords of default accounts after applying updates. Accounts no longer in use should be removed from the authorization file and rights database. Dormant accounts should be set to DISUSER.
Intruders also try guessing simple user passwords. See the discussion on weak passwords in Section A for suggestions on choosing good passwords.
If intruders get into a system, they often modify the programs patch.exe, loginout.exe, and show.exe. Compare these programs with those found in your distribution media.
| The CERT Coordination Center does not formally review, evaluate, or endorse the tools and techniques described. The decision to use the tools and techniques described is the responsibility of each user or organization, and we encourage each organization to thoroughly evaluate new tools and techniques before installation or use. |
If your UNIX system has a shadow password capability, you should consider using it. Under a shadow password system, the /etc/passwd file does not have encrypted passwords in the password field. Instead, the encrypted passwords are held in a shadow file that is not world readable. Consult your system manuals to determine whether a shadow password capability is available on your system and to get details of how to set up and manage such a facility.
COPS is a publicly available collection of programs that attempt to identify security problems in a UNIX system. COPS does not attempt to correct any discrepancies found; it simply produces a report of its findings. COPS is available by anonymous FTP from
ftp://info.cert.org/pub/tools/cops
and by uucp from
uunet.uu.net
npasswd is a program suite that allows a system manager to enforce policies for selecting passwords. This software is available by anonymous FTP from
ftp://ftp.cc.utexas.edu:/pub/npasswd/npasswd.tar.Z
This program provides additional network logging information and gives a system administrator the ability to deny or allow access from certain systems or domains to the host on which the program is installed. Installation of this software does not require any modification to existing network software or network configuration files. This program is available by anonymous FTP from
ftp://info.cert.org/pub/tools/tcp_wrappers
Crack is a freely available program designed to identify standard UNIX DES encrypted passwords that can be found in widely available dictionaries by standard guessing techniques outlined in the Crack documentation.
Many system administrators run Crack as a regular system administration procedure and notify account owners who have "crackable" passwords. Crack is available by anonymous FTP from
ftp://info.cert.org/pub/tools/crack
lsof lists open files for running UNIX processes. lsof is available by anonymous FTP from
ftp://vic.cc.purdue.edu:/pub/tools/unix/lsof
MD5 is a cryptographic checksum program. MD5 takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is thought to be computationally unfeasible to produce two messages having the same message digest or to produce any message having a given prespecified target message digest. MD5 is found in RFC 1321. It is available by anonymous FTP from
ftp://info.cert.org/pub/tools/md5
Tripwire checks file and directory integrity; it is a utility that compares a designated set of files and directories to information stored in a previously generated database. Any differences are flagged and logged, including added or deleted entries. When run against system files on a regular basis, Tripwire enables you to spot changes in critical system files and to immediately take appropriate damage control measures. Tripwire is available by anonymous FTP from
ftp://info.cert.org/pub/tools/tripwire
This program can be run on UNIX systems to identify network interfaces that are in debug or promiscuous mode. Network interfaces in these modes may be the sign of an intruder performing network monitoring to steal passwords and other traffic (see CERT advisory CA-94:01).
The program does not print any output (unless -v is given) unless it finds interfaces in "bad" modes. So, it's easy to run ifstatus from cron once an hour or so. If you have a modern cron that mails the output of cron jobs to their owner, use a line like this:
00 * * * * /usr/local/etc/ifstatus
If you have a version of cron that doesn't do this, use the "run-ifstatus" shell script instead (edit it to use the right path to the command):
00 * * * * /usr/local/etc/run-ifstatus
If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST).
Internet E-mail: cert@cert.org
Telephone: 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),
and are on call for emergencies during other hours.
CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890
The CERT Coordination Center issues CERT advisories and bulletins, which warn you about problems and inform you about preventive techniques. We maintain a CERT advisory mailing list, which is also distributed via the USENET newsgroup comp.security.announce. If you are unable to receive the newsgroup comp.security.announce and would like to be added to the advisory mailing list, send mail to
Past advisories and bulletins, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org.
Copyright 1995 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
The CERT Coordination Center is sponsored by the Advanced Research Projects Agency (ARPA). The Software Engineering Institute is sponsored by the U.S. Department of Defense.