Author:              CERT(sm) Coordination Center
                Date:                January 1996
                HTML-Version:        Markus Hübner

The information in this document can help you:

• Determine whether or not your site may have had a break-in.
• Assess the security of your site.
• Learn how to make your site more secure.

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.

How To Determine Whether Your System Has Been Compromised

1. Examine log files such as your 'last' log, process accounting, syslog, and C2 security logs for logins from unusual locations or other unusual activity. Note that this is not foolproof; many intruders edit accounting files in an attempt to hide their activity.

2. Look everywhere on the system for unusual or hidden files (files that start with a period and are normally not shown by ls) as these can be used to hide information such as password cracking programs and password files from other systems. A favorite trick on UNIX systems is to put a hidden directory in a user's account with an unusual name, something like '...' or '.. ' (dot dot space space) or '..^G' (dot dot control-G). Also, files with names such as '.xx' and '.mail' have been used.

3. Look for setuid files (especially setuid root files) everywhere on your system. Intruders often leave setuid copies of /bin/sh around to allow them root access at a later time. The UNIX find(1) program can be used to hunt for setuid files. You can use the following command to find setuid root files on the entire file system. Note that this searches the entire directory tree, including NFS/AFS mounted file systems.

           	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

4. Check your system binaries to make sure that they haven't been changed. We've seen intruders change programs on UNIX systems such as login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync, any binaries referenced in /etc/inetd.conf, and other critical network and system programs. On VMS systems, we've seen intruders change programs such as loginout.exe and show.exe. Compare the versions on your systems with known good copies such as those from your initial installation tapes. Be careful of trusting backups; your backups could also contain Trojan horses.
   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.

5. Examine all the files that are run by cron and at. We've seen intruders leave back doors in files run from cron or submitted to at. These techniques can let an intruder back on the system even after you've kicked him or her off. Also, verify that all files/programs referenced (directly or indirectly) by the cron and at jobs, and the job files themselves, are not world-writable.

6. Inspect /etc/inetd.conf for unauthorized additions or changes. In particular, search for entries that execute a shell program (for example, /bin/sh or /bin/csh) and check all programs that are specified in /etc/inetd.conf to verify that they are correct and haven't been replaced by Trojan horse programs.

7. Check your system and network configuration files for unauthorized entries. In particular, look for '+' (plus sign) entries and inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd, and in all .rhosts files (especially root, uucp, ftp, and other system accounts) on the system. These files should not be world-writable. Furthermore, ensure that these files existed prior to any intrusion and have not been created by the intruder.

8. Examine all machines on the local network when searching for signs of intrusion. Most of the time, if one host has been compromised, others on the network have been too. This is especially true for networks where NIS is running or where hosts trust each other through the use of .rhosts files and/or /etc/hosts.equiv files. Also, check any hosts with which your users share .rhosts access.

9. Examine the /etc/passwd file on the system and check for any additional or modified accounts. In particular, look for the unauthorized creation of new accounts, accounts with no passwords, or UID changes (especially UID 0) to existing accounts.

UNIX System Configuration Problems That Have Been Exploited

1. Weak passwords

   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.

2. Accounts without passwords or default passwords

   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.

3. Reusable passwords

   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

4. Use of TFTP (Trivial File Transfer Protocol) to steal password files

   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.

5. Vulnerabilities in sendmail

   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:

      	     telnet  25

   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.

6. Old versions of FTP; misconfigured anonymous FTP

   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

7. Inappropriate network configuration file entries

   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.

8. Misconfiguration of uucp

   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.

9. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab

   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.

10. Inappropriate entries in /usr/lib/aliases

    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.

11. Inappropriate file and directory protections

    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.

12. Old versions of system software

    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.

13. Use of setuid shell scripts

    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.

14. Inappropriate export settings

    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.

VMS System Vulnerabilities

1. Accounts with known default passwords

   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.

2. Unauthorized versions of system files

   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.

Software Tools To Assist In Securing Your System

1. Shadow passwords

   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.

2. COPS (The Computer Oracle and Password System)

   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

3. npasswd

   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

4. TCP/IP wrapper program

   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

5. Crack

   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

6. lsof

   lsof lists open files for running UNIX processes. lsof is available by anonymous FTP from

   ftp://vic.cc.purdue.edu:/pub/tools/unix/lsof

7. MD5

   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

8. Tripwire

   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

9. ifstatus

   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.

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.