Hackers Toolkit 2.0/Hackers_Toolkit_v2.0.iso/HTML/archive/Texts/Improving-Security/security2.txt

Text File | 1999-11-04 | 21.9 KB | 483 lines

               Author:              CERT(sm) Coordination Center

                Date:                January 1996

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

     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.

     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.

     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

     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.

     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.

     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

     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.

     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.

     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.

     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.

     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.

     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.

     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.

     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

     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.

     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

 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.

     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.

     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

     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

     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

     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

     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

     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

     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

     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: [e-mail]

Telephone: [phone] (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

     [e-mail]

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.

                         Back to the Security-Page