krvw@sei.cmu.edu (Kenneth Van Wyk) (08/16/89)
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 following: o 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: o 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. o 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. o Monitor system logs - System access logs should be periodically scanned (e.g., via UNIX "last" command) for suspicious or unlikely system activity. o 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. o 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. o 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 structure. o 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). Kenneth R. van Wyk Computer Emergency Response Team cert@SEI.CMU.EDU (412) 268-7090 (24 hour hotline)
smart@ditmela.oz (Robert Smart) (08/19/89)
Australia is about to establish a Research network. Security is a hot topic. I have been arguing the need for the network to have a security officer to coordinate security measures, and to cooperate with other research networks and with computer vendors on security matters. So I am pleased to hear about the Computer Emergency Response Team. In article <3858@fy.sei.cmu.edu> krvw@sei.cmu.edu (Kenneth Van Wyk) writes: > > o 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". It seems that the code could easily be written so that "strings" doesn't show anything. > > o 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. Is "sum" designed to be a security device? If not it is probably easy to arrange for the checksum to be unchanged. I would like to see a checksum like program that was designed like an encryption algorithm: very hard to alter and keep the checksum the same. > o Apply fixes - Many of the old "holes" in UNIX have been closed. > Check with your vendor and install all of the latest fixes. Vendors remain shockingly unconcerned about security issues. What do we do about machines which don't have software maintenance? Should they be barred from Internet access? Since the BSD 4.3 network stuff is publically available I think we should be able to plug network holes in unix systems, even for machines which don't have software maintenance. > > If system administrators do discover any unauthorized system activity, > they are urged to contact the Computer Emergency Response Team (CERT). > So what does CERT do between emergencies? What I would like to see is the creation of a shell script to check machines out for security. It should be something like the "rn" installation script [a brilliant bit of work]: work out what its environment is, and make appropriate investigations and even offer to install updated software where appropriate: It might go like this: % security-check Still running SunOS 3.5 eh? For internet network performance you should switch to a more recent version. Gack! You're still running the old fingerd. You must remove it! Would you like me to install a safe version [yn]? etc. The shell script should also check for obvious bad passwords: words, first names, password=login name, etc. It should check for potential configuration problems (like + in hosts.equiv). It would be nice to see similar mechanisms for other common operating systems, which probably means VMS. This would require cooperation from the vendors of VMS tcp/ip software. Non-cooperaters banned from the internet! Another thing CERT could do is check machines from the internet to see if they exhibit known security bugs. Bob Smart <smart%ditmela.oz.au@uunet.uu.net>