U.S. DOE's Computer Incident Advisory Capability ___ __ __ _ ___ __ __ __ __ __ / | /_\ / |\ | / \ | |_ /_ \___ __|__ / \ \___ | \| \__/ | |__ __/ Number 95-07 March 29, 1995 In order to provide timely, useful information on the upcoming release of the SATAN tool, CIAC is releasing a special issue of CIAC Notes. Please send your comments and feedback to ciac@llnl.gov. $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ $ Reference to any specific commercial product does not necessarily $ $ constitute or imply its endorsement, recommendation or favoring by $ $ CIAC, the University of California, or the United States Government.$ $-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$-$ A Look at SATAN John Fisher CIAC Team ciac@llnl.gov Introduction Security Administrator Tool for Analyzing Networks, or SATAN, is a tool for investigating the vulnerabilities of remote systems. Systematically moving through a given Internet subdomain, it probes for weakness in each responding system. The vulnerabilities uncovered are then reported to the user. Due to be released April 5, SATAN is the joint work of Dan Farmer, author of COPS (Computer Oracle and Password System), and Wietse Venema, from the Eindhoven University of Technology in the Netherlands. This project is a private effort on their part, and the final product is to be freely available to anyone on the Internet. Although it hasn't hit the Internet yet, SATAN is guaranteed to have a large impact on its security. SATAN is being promoted as a security tool for system administrators, not an attack tool for crackers. Unfortunately, it can be utilized in either manner. It is up to system administrators to decide what its impact will be. The safety of any particular system is dependent on who utilizes SATAN first. Searching for system vulnerabilities is not a new idea. COPS will report many common vulnerabilities on a single system, by analyzing the system it resides on. Tools which probe for vulnerabilities on remote systems are not a new idea either. The Internet Security Scanner (ISS), written by Christopher Klaus, has been available in both public and commerical versions for several years. While it certainly simplified probing of remote systems, the public version was not particularly powerful. It lacked a user interface, and provided a limited set of attacks. In contrast, SATAN is considerably more powerful, and utilizes a World Wide Web (WWW) client to provide a friendly, point and click interface. Extensive information is provided that explains what vulnerabilities are being identified, and how those vulnerabilities can be removed. How It Works All information provided here relates to version 0.33 of the beta release. SATAN is made up of HyperText Markup Language (HTML) documents, C code, and Perl scripts which generate HTML code dynamically. It requires an HTML viewer (Mosaic, Netscape, or Lynx), a C compiler, and PERL version 5. The user simply interacts with a WWW client, entering necessary data into forms. The control panel for SATAN provides four hypertext options: Target Selection, Reporting & Data Analysis, Documentation, and Configuration & Administration. Through Target Selection, the user can enter a machine or a domain of machines to attack, and the extent of the attack (Light, Normal, Heavy). A Light attack will simply report what hosts are available, and what Remote Procedure Call (RPC) services they offer. A Normal attack will probe the targets by establishing finger, telnet, FTP, WWW, gopher, and SMTP connections. These will be used to establish what the operating system is, and what vulnerabilities may be available. A Heavy attack will additionally search for several other known vulnerabilities, such as writable anonymous ftp directories or trusted hosts. Once the targets and extent of probing are established, a simple mouse click will begin the analysis. When finished, the user finds the results in the Reporting & Data Analysis link. SATAN is highly customizable and extendible. Through configuration files, numerous default values can be modified. New probes to be performed on each host may be added by writing a program (or script) with the proper input and output, and naming it with an extension of ".satan." This will allow users to write their own attacks tools, and add them to SATAN in a plug-and-play manner. Protecting Against SATAN Attacks By configuring a system correctly, installing all the latest patches, and monitoring system usage, most of SATAN's techniques can be countered, or at a minimum detected. Unfortunately, complete protection from SATAN is difficult. Most of the vulnerabilities it looks for are easily addressable, but some do not yet have satisfactory solutions. Of course, the configuration problems should be addressed immediately, once uncovered. The more serious vulnerabilities may be addressed by stopping the vulnerable service, or placing a firewall around the vulnerable set of hosts. Below is a summary of vulnerabilities that SATAN exploits, chiefly borrowed from the SATAN documentation itself. By effectively addressing these vulnerabilities, system administrators can prevent most attacks. Unprivaleged NFS Access NFS suffers from a poor authentication algorithm. The standard authentication mechanism it uses, AUTH_UNIX, uses a UID, GID pair to authorize that an NFS request is legitimate. But, NFS requests may be spoofed by user programs, fooling NFS into granting file access to arbitrary users. Although special authentication is done by AUTH_UNIX for root privileges to a filesystem, this may be obtained as well. This is not an easy problem to fix. Of course, make sure that all NFS security patches have been installed. The best bet is to find a new implementation of NFS, one which supports DES encryption, and utilizes AUTH_DES authorization. A partial solution is to configure NFS so that requests are only accepted from privileged system programs (making spoofing more difficult). Then, a user must at least be root on a remote system in order to send NFS requests. NFS file systems exported to arbitrary hosts File systems exported under NFS should be mountable only by a restricted set of hosts. The UNIX "showmount" command will display filesystems exported by a given host: %/usr/etc/showmount -e hostname export list for hostname: /usr hosta:hostb:hostc /usr/local (everyone) The above output indicates that this NFS server is exporting two partitions: /usr, which can be mounted by hosta, hostb, and hostc; and /usr/local which can be mounted by anyone. In this case, access to the /usr/local partition should be restricted. Whenever possible, file systems should be exported read-only. Regardless of the export privileges, a limited set of hosts should be explicitly defined in the /etc/exports file. A sample file might be as follows: /usr -ro,access=hosta.domain:hostb.domain /usr/local -access=hosta.domain Here, /usr is available for read-only access by hosta and hostb. /usr/local is available for read/write access, but only by hosta. Consult the system manual entry for "exports" or "NFS" for more information. NFS file systems exported via the portmapper On BSD systems, the portmap is used to convert TCP/IP protocol port numbers into RPC program numbers. A host can gain access to another host's file systems by tricking its portmapper into making NFS requests. Because NFS trusts the portmapper, one could gain access to an exported file system. Since most exported file systems are user home directories, this vulnerability can be used as a stepping stone to gaining root access. Several steps can be taken to avoid this vulnerability. First, a portmapper should be used which does not forward mount requests, if the host is a BSD system. Wietse Venema has written a more secure portmapper, available at ftp://ftp.win.tue.nl/pub/security/portmap_3.shar.Z. For System V based systems, a similar tool has been written by Venema which is a replacement for rpcbind. It may be found at ftp://ftp.win.tue.nl/pub/security/rpcbind_1.1.tar.Z. Second, more caution should be used when exporting file systems. File systems should be exported as read-only when possible, and an export list should not include the exporting server. NIS password file access from arbitrary hosts The NIS (Network Information Server) provides user information (including encrypted passwords) to other hosts on a network. Unfortunately, very little host authentication is performed, and it is easy for external hosts to obtain user passwords (and other information). A password cracker can then be used to obtain a login. The best solution is to update NIS to provide some more complete access control mechanisms. Unfortunately, not all vendors are providing this yet. A portmapper with tighter access control mechanisms may work as well. Several patches for NIS running on SunOS are discussed in CIAC Bulletin C-25. A strongly enforced policy for good passwords is probably as important as a secure NIS. Several passwd alternatives are available which require the user to enter more complex passwords, such as npasswd (ftp://ftp.cc.utexas.edu/pub/npasswd/npasswd.tar.Z). REXD access from arbitrary hosts The UNIX remote execute server rexd provides only minimal authentication and is easily subverted. It should be disabled by placing a "#" at the beginning of the rexd line in the file /etc/inetd.conf and then resetting the inetd process ("refresh -s inetd" on AIX systems, killing and restarting inetd on others). The disabled entry in /etc/inetd.conf should resemble the following: #rexd/1 stream rcp/tcp wait root /usr/etc/rexd rexd Arbitrary files accessible via TFTP TFTP provides remote access to a host's files without asking for a password. While handy for booting diskless workstations, it is inherently a very dangerous security problem, and there is infrequent reason to use it. The best thing to do is to just disable completely, by placing a "#" at the beginning of the tftp line in /etc/inetd.conf. If that is not possible, only a limited portion of the file system should be available to TFTP users. This can be done by changing the root directory when the tftp daemon is executed. See the tftpd documentation for more details. Remote shell access from arbitrary hosts By entering a "+" in the /etc/hosts.equiv, or "+ +" in /.rhosts, a host can open itself up to the entire world. Anyone on the Internet can log in without being asked for a password. This of course should be avoided at all costs. Many systems are shipped in this manner, so be sure to check. The package logdaemon provides replacements for rlogind, rshd, etc. They provide better handling of the hosts.equiv and .rhosts files, such as the rejection of wildcards. The package can be found at ftp://ftp.win.tue.nl/pub/security/logdaemon-4.7.tar.gz. X server access control disabled The X Windows client/server model is extremely powerful, but improper use of its capabilities can lead to serious security problems. If access control is disabled, via the "xhost +" command, any remote user will be able to read/write screen information, control I/O behavior, and even capture user keystrokes. To avoid these problems, all "xhost +" commands should be removed from the .Xsession file, each user's .Xsession file, and any application program or shell script that may contain it. The ability to access a particular X server remotely should always be granted on a limited basis. The xhost program should really be avoided entirely. Instead, the xauth program should be used, using either MIT-MAGIC-COOKIE or SUN-DES authentication. See the xauth man pages for more details. Writable anonymous FTP home directory If the permissions are set incorrectly on the anonymous FTP home directory, any user may log in, and either add a .rhosts file (which could allow a shell session), or may be able to replace files. The best way to avoid this problem is to have all system files and directories under the anonymous FTP home directory owned and writable solely by root. Making "/bin/false" the shell will have the additional effect of disallowing shell sessions with the ftp account. For more information on securing anonymous FTP and other information servers, see the CIAC Document CIAC-2308 R.2 (http://ciac.llnl.gov/ciac/documents/ciac2308.html). The above information is fairly limited in details. The best source for understanding the vulnerabilities exploited by SATAN is SATAN itself. Every system administrator should read through the documentation it provides, and understand how to cover the holes it exploits. CIAC has recently written a program to defend against SATAN and other similar tools. The program, called Courtney, monitors the connections to the ports probed by SATAN. When an attack by SATAN takes place, the offending host will be reported. More information on this tool is available at http://ciac.llnl.gov/ciac/ToolsUnixNetMon.html#Courtney. Verify that the MD5 checksum of the compressed tar file has a value of 9fbc0142fdbe7911e63ae5905911e2c7. CIAC offers several powerful tools to DOE and DOE contractors for inspecting UNIX based systems, and offering additional protection against SATAN. The Security Profile Inspector (SPI) provides a powerful suite of security inspections, using a straightforward menu-based interface. More information about SPI is available from http://ciac.llnl.gov/cstc/CSTCProducts.html#spi. The Network Intrusion Detector (NID) provides a suite of security tools for detecting and analyzing network intrusions. More information on it is available from http://ciac.llnl.gov/cstc/CSTCProducts.html#nid. ------------------------------ Who is CIAC? CIAC is the U.S. Department of Energy's Computer Incident Advisory Capability. Established in 1989, shortly after the Internet Worm, CIAC provides various computer security services free of charge to employees and contractors of the DOE, such as: . Incident Handling Consulting . Computer Security Information . On-site Workshops . White-hat Audits CIAC is located at Lawrence Livermore National Laboratory in Livermore, California, and is a part of its Computer Security Technology Center. Further information can be found at CIAC. CIAC is also a founding member of FIRST, the Forum of Incident Response and Security Teams, a global organization established to foster cooperation and coordination among computer security teams worldwide. See FIRST for more details. ------------------------------ Contacting CIAC DOE and DOE contractor sites can contact CIAC at: Voice: 510-422-8193 FAX: 510-423-8002 STU-III: 510-423-2604 E-mail: ciac@llnl.gov For DOE and DOE contract site emergencies only, call 1-800-SKYPAGE (1-800-759-7243) and enter PIN number 8550070 (primary) or 8550074 (secondary). Previous CIAC notices, anti-virus software, and other information are available via WWW (http://ciac.llnl.gov/) and anonymous FTP from ciac.llnl.gov (IP address 128.115.19.53). CIAC has several self-subscribing mailing lists for electronic publications: 1. CIAC-BULLETIN for Advisories, highest priority - time critical information and Bulletins, important computer security information; 2. CIAC-NOTES for Notes, a collection of computer security articles; 3. SPI-ANNOUNCE for official news about Security Profile Inspector (SPI) software updates, new features, distribution and availability; 4. SPI-NOTES, for discussion of problems and solutions regarding the use of SPI products. Our mailing lists are managed by a public domain software package called ListProcessor, which ignores E-mail header subject lines. To subscribe (add yourself) to one of our mailing lists, send requests of the following form: subscribe list-name LastName, FirstName PhoneNumber as the E-mail message body, substituting CIAC-BULLETIN, CIAC-NOTES, SPI- ANNOUNCE or SPI-NOTES for list-name and valid information for LastName FirstName and PhoneNumber. Send to: ciac-listproc@llnl.gov (not to: ciac@llnl.gov) e.g., subscribe ciac-notes O'Hara, Scarlett W. 404-555-1212 x36 subscribe ciac-bulletin O'Hara, Scarlett