============================================================================= AA-95.03 AUSCERT Advisory April 3, 1995 An overview of SATAN ----------------------------------------------------------------------------- There has been a lot of speculation in the internet community in anticipation of the release of the Security Administrator Tool for Analyzing Networks (SATAN). AUSCERT have decided to release this advisory in order to dispel some of the confusion about the nature of the tool and its uses. Questions that we will be answering in this document are: 1.0 General 1.1 What is SATAN? 1.2 Does SATAN break into systems? 1.3 Preparing for the release of SATAN 1.4 What vulnerabilities does SATAN check for? 2.0 Requirements 2.1 What will you need in order to run SATAN? 3.0 Availability 3.1 Where can you get a copy of SATAN? 3.2 When will SATAN be available? 4.0 Post Release 4.1 What are the possible effects of the release of a tool such as SATAN? 4.2 How can you tell if you are being scanned by someone using SATAN? Appendix A: Discussion of vulnerabilities identified by SATAN. Much of the detail in this advisory is drawn from the pre-release SATAN documentation available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/satan_doc* ------------------------------------------------------------------------------- 1.0 General 1.1 What is SATAN? SATAN (the Security Administrator Tool for Analyzing Networks) is a testing and reporting tool that collects a variety of information about networked hosts. SATAN has been designed to help systems administrators to automate the process of testing their systems for known vulnerabilities that can be exploited via the network. This will be particularly useful for networked systems with multiple hosts. It will also be particularly useful to would-be intruders looking for systems with security holes. Herein lies the controversy. SATAN is written mostly in Perl and utilizes a HTML Web browser such as Netscape, Mosaic or Lynx to provide the user interface. This easy to use interface drives the scanning process and presents the results in summary format. As well as reporting the presence of vulnerabilities, SATAN also gathers large amounts of general network information, such as which hosts are connected to subnets, what types of machines they are and which services they offer. SATAN can be configured to scan at 3 levels: light This is the least intrusive scan. SATAN collects information from the DNS (Domain Name System), tries to establish what RPC (Remote Procedure Call) services the host offers and what file systems it shares via the network. With this information, SATAN finds out the general character of a host (file server, diskless workstation). normal (includes light scan probes) At this level, SATAN probes for the presence of common network services including finger, remote login, ftp, WWW, Gopher and email. With this information, SATAN establishes the operating system type and, where possible, the software release version. heavy (includes normal scan probes) After it has found out what services are offered by the target, SATAN looks at them in more depth and does a more exhaustive scan for network services offered by the target. At this scanning level it checks for the vulnerabilities it is configured to check. (see below for a list of these). These are the default settings for each level. SATAN can easily be configured to do more or less scanning at each level. It is worth noting that SATAN can only scan hosts that are visible on the network. External users can not probe hosts behind a suitably configured firewall. 1.2 Does SATAN break into systems? SATAN is a reporting and analysis tool only. As distributed, it does not break into systems. However SATAN is modular and easily extended, so after it is released modified versions could be designed to compromise systems. 1.3 Preparing for the release of SATAN SATAN tests for the presence of several known vulnerabilities, each of which has a workaround or solution available. It is strongly recommended that you apply the workarounds and solutions discussed in Appendix A before April 5, 1995. The discussions in Appendix A draw directly from the SATAN documentation. Please note that securing your hosts against the vulnerabilities tested for by SATAN does not necessarily make your hosts secure. It is imperative that you continue to take all of the usual security measures, like applying all security patches and performing regular monitoring activities. It is strongly recommended that you review all Unix hosts with the AUSCERT Unix Security Checklist. This document is available via anonymous ftp from ftp://ftp.auscert.org.au/pub/auscert/papers/unix_security_checklist_1.0 1.4 What vulnerabilities does SATAN check for? SATAN comes configured to test for the following eleven vulnerabilities. 1. Are NFS file systems exported to unprivileged programs? 2. Are NFS file systems exported to arbitrary hosts? 3. Are NFS file systems exported via the portmapper? 4. Is there NIS password file access from arbitrary hosts? 5. Is there REXD access from arbitrary hosts? 6. Are arbitrary files accessible via TFTP? 7. Is remote shell access available from arbitrary hosts? 8. Is X server access control disabled? 9. Is there a writable anonymous FTP home directory? 10. Is there an insecure version of sendmail in use? 11. Is there an insecure version of wu-ftpd in use? None of these vulnerabilities/problems are new. All of them are well known and have been used by intruders in the past. SATAN makes spotting these vulnerabilities simple, both for the systems administrator and for anyone else looking for vulnerabilities on the network. See Appendix A for a detailed overview of these vulnerabilities and their suggested solutions. SATAN is also configurable. You can add program modules to implement checks of your own devising. ------------------------------------------------------------------------------- 2.0 Requirements 2.1 What will you need in order to run SATAN? The pre-release implementation of SATAN is supported for SunOS 4.1.x, Solaris and IRIX. The official release should support many more systems. In order to run it effectively you will need: 32M memory 20M disk space(Includes space for supplementary packages such as perl5 and Mosaic) HTML viewer (like Mosaic/Netscape/Lynx) perl5 C compiler ------------------------------------------------------------------------------ 3.0 Availability 3.1 Where can you get a copy of SATAN? AUSCERT will be mirroring SATAN when it is released. It will be available from our ftp server at ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/satan* A pre-release documentation package is already available. It contains a copy of SATAN with all the processing software removed. It is worth getting a copy of this, installing it and having a look at the sample database and documentation pages. This is a good introduction to the product and should help answer any questions you have about it. AUSCERT currently mirror this on our anonymous ftp server at ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/satan_doc* 3.2 When will SATAN be available. SATAN is scheduled for release on April 5, 14:00 GMT. This is 00:00 AEST on the 6th of April. The software will be available on AUSCERT's ftp site at 00:00 AEST on Thursday the 6th of April. ------------------------------------------------------------------------------ 4.0 Post Release 4.1 What are the possible effects of the release of a tool such as SATAN? 1) Increased interest in computer cracking by everyone including the media. 2) Increased awareness of the specific vulnerabilites that SATAN tests for. 3) Increased interest in the specific vulnerabilites that SATAN tests for by intruders and wannabees. 4) Increased accessability/knowledge of what services are available on hosts visible on the network. 5) Increased probing of sites by outsiders (both intentionally and unintentionally). 4.2 How can you tell if you are being scanned by someone using SATAN? As part of a heavy scan, SATAN will attempt to access many ports and services in a very short space of time. However, many UNIX network daemons do not provide sufficient logging to determine if a system is being probed by SATAN. For daemons started by inetd (rshd, telnetd, ftpd and so on) this level of logging can be provided by tcp_wrappers. A heavy scan should be identified readily in tcp_wrapper logs. As well as logging, tcp_wrappers also provide access control to most network services. tcp_wrappers is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/ tcp_wrappers_7.2.tar.gz We strongly recommend that you install and run tcp_wrappers. Other tools which also provide extra logging (plus other features including access control) include portmap_3, rpcbind-1.1 and logdaemon-4.7. Details of these can be found in "Appendix A" as they directly provide workarounds or solutions to certain vulnerabilities. CIAC (U.S. Dept. of Energy's Computer Incident Advisory Capability) have written a tool to monitor the network and identify the source of a port scanner (such as used by SATAN in heavy scan). The program, called Courtney, monitors connections to the ports probed by SATAN. When a scan is noticed, the probing host is reported. This tool is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ciac.llnl.gov/sectools/unix/courtney* ========================================================================== Appendix A Discussion of vulnerabilities identified by SATAN The discussions in this appendix draw directly from the SATAN documentation, "Vulnerabilities -- a Tutorial." The "See also" sections may include added material and references not found in the original SATAN documentation. It is suggested that the CERT advisories referenced in the vulnerability information be reviewed to gain a greater understanding of the workarounds and solutions to particular vulnerabilities. Also the advisories often give more detailed instructions for applying the solutions/workarounds. ------------------------------------------------------------------------------ A.1 Writable FTP home directory A.1.1 The Problem When the FTP home directory of a UNIX host is writable, a remote intruder can upload a .rhosts or .forward file to gain access to the system, or may be able to replace files. When a PC (DOS or MAC) permits anonymous users write access to its file system, a remote intruder may be able to replace arbitrary programs or configuration files, or corrupt the file system by filling it up. A.1.2 Fix for UNIX Systems Make sure that the FTP home directory, and all system files and directories below it, are owned by root. Make sure that they are not writable by anonymous users. As a rule, no file or directory should be owned by the FTP account. A.1.3 Other tips for UNIX Systems Change the login shell of the ftp account to /bin/false. A.1.4 See also 1) AUSCERT's UNIX Security Checklist (section 3.0) 2) CERT document about secure writable anonymous ftp from ftp://ftp.auscert.org.au/pub/cert/tech_tips/anonymous_ftp 3) CIAC document about anonymous ftp from ftp://ftp.auscert.org.au/pub/mirrors/ciac.llnl.gov/ciacdocs/ciac2308.txt --------------------------------------------------------------------------- A.2 Unprivileged NFS access A.2.1 Background When an NFS client host wants to access a remote file or directory, its operating system sends a request to the NFS server. The request specifies, among others, a file identifier, the operation (read, write, change permission, etc.), and the identity of the user on whose behalf the operation is to be done. By default, the user identity is specified with the UNIX numeric user and group ids. With this scheme, also called AUTH_UNIX, the server simply believes anything that the client sends it. A.2.2 The Problem An NFS request is nothing but a network message. Any user can run a program that generates arbitrary NFS requests. Such programs have been available for several years, and writing them does not require unusual programming skills. When an NFS server accepts requests with AUTH_UNIX authentication from unprivileged user programs, a malicious user can execute file access requests on behalf of any user. Reason: with AUTH_UNIX authentication, the user identity is nothing but a few user and group ID numbers in a network message. A.2.3 Fix The fix is to avoid AUTH_UNIX authentication and to use something that involves cryptography. For example, secure NFS with DES or Kerberos credentials. Unfortunately, many NFS implementations support AUTH_UNIX authentication only. Consult your system documentation. A partial, but more common, solution is to configure the NFS server, and where possible, the mount daemon, to accept requests only from privileged system programs (such as UNIX kernels), and to reject NFS requests that are sent by unprivileged user programs. SunOS 4 administrators modify /etc/rc.local rpc.mountd (no -n option) echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem SunOS 5 administrators modify /etc/system set nfs:nfs_portmon = 1 On other systems, the mountd command-line options differ, and the kernel variable may be called nfsportmon or something similar. Note: rejecting NFS requests from unprivileged user programs does not protect your servers against malicious superusers or against malicious PC programs. A.2.4 Other tips Where practical, export file systems read-only. Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers. A.2.5 See also 1) AUSCERT's UNIX Security Checklist (section 2.5) --------------------------------------------------------------------------- A.3 Unrestricted NFS export A.3.1 The Problem When a file system is exported without restriction, an intruder can remotely compromise user or system files, and then take over the machine. For example, an intruder can remotely replace a system program or configuration file, like .rhosts (to obtain interactive access) or .forward (to obtain non-interactive access). A.3.2 Fix Make sure all file exports specify an explicit list of clients or netgroups. Export file systems read-only where possible. A.3.3 Other tips Some versions of the NFS mount daemon cannot expand large netgroups and will export to the world anyway; see also Cert advisory CA-94:02. Check your vendor patch list. In NIS netgroup members, empty host fields are treated as wildcards and cause the mount daemon to grant access to any host. Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers. A.3.4 See also 1) AUSCERT's UNIX Security Checklist (section 2.5) --------------------------------------------------------------------------- A.4 NIS password file access A.4.1 Background The NIS (Network Information Service) implements network-wide access to administrative information. Examples of databases (also called NIS maps) that are shared via NIS: the password file that describes what users have access to the system, the table with names and addresses of hosts on the network, electronic mail aliases. NIS databases are organized in domains. One NIS server can serve multiple NIS domains. In order to perform a query, a client sends a request to a NIS server and specifies a NIS domain name, the name of the database (NIS map) to be searched, a search key. A.4.2 The Problem Many NIS implementations provide no access control. Every host that asks for information will receive a reply. In order to perform a query, one needs to know the server's NIS domain name. Often, this name is easy to guess, or it can be obtained via the bootparam network service. When the local network is accessible from other networks, a remote intruder can collect password file information and run a password guessing program. Many people (including Dan Klein) have demonstrated that people tend to choose passwords that are easy to guess. A.4.3 Fix Several vendors have added access control to their ypserv implementation. Check your system documentation or vendor patch list. The control file is sometimes called securenets. A.4.4 Workarounds Run a portmapper with access control. A.4.5 Other tips Consider blocking ports 111 (portmap) on your network gateway. This makes attacks on NIS and NFS mount daemons much harder. Enforce a policy for choosing passwords by installing an alternative passwd command, for example anlpasswd. A.4.6 See also 1) AUSCERT's UNIX Security Checklist (sections 2.3, 2.12 and 4.4 ) 2) CERT advisory CA-92:13.SunOS.NIS.vulnerability CERT advisory CA-93:01.REVISED.HP.NIS.ypbind.vulnerability ftp://ftp.auscert.org.au/pub/cert/cert_advisories/{CA-92:13*,CA-93:01*} 3) anlpasswd is available from ftp://ftp.auscert.org.au/pub/mirrors/info.mcs.anl.gov/anlpasswd.tar.Z --------------------------------------------------------------------------- A.5 Portmapper exports A.5.1 Background In order to perform operations via the NFS network file system protocol, a client host sends NFS requests to the NFS server daemon with: an NFS file handle that specifies the target of the operation, the operation (lookup, read, write, change permissions), the user on whose behalf the request is sent. When an NFS client host wants to access a remote file system for the first time, it first needs to obtain an NFS file handle. To this end, the client host sends a mount request to the server's mount daemon. The server's mount daemon verifies that the client host has permission to access the requested file system. When the mount daemon grants access, it sends a (directory) file handle back to the NFS client. A.5.2 The problem For efficiency reasons, most NFS export restrictions are enforced by the mount daemon. Individual file access operations are handled by the NFS daemon, and the origin of such requests is examined only in special cases such as remote superuser access. Instead of talking directly to the mount daemon, a malicious NFS client can ask the server's portmapper daemon to forward the request to the mount daemon. When the mount daemon receives the request from the portmapper, the mount daemon will believe that the request comes from the file server, and not from the malicious client. When the file server exports file systems to itself (for example, because the server is a netgroup member) the mount daemon grants access and replies with a file handle. The portmapper forwards the handle to the malicious client. From now on, the client can talk directly to the server's NFS daemon to access the directory and all files below it. A.5.3 Fix Run a portmapper (or rpcbind program in case of System V.4) that does not forward mount etc. requests. Consult your vendor's patch list. See also: Cert Advisory 94:15. A.5.4 Other tips Export file systems read-only where possible. Consider blocking ports 2049 (nfs) and 111 (portmap) on your routers. A.5.5 See also 1) CERT Advisory CA-94:15.NFS.Vulnerabilities ftp://ftp.auscert.org.au/pub/cert/cert_advisories/CA-94:15.* 2) Wietse Venema has written a portmapper with access control plus other enhancements, portmap_3. Also available is a replacement rpcbind. These can can be found on: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/ {portmap_3.shar.Z,rpcbind_1.1.tar.Z} --------------------------------------------------------------------------- A.6 REXD access A.6.1 Background The rexd service, and the on client program, implement remote command execution via the network. To the extent that it is possible, the complete client environment, including working directory and environment variables, is made available on the remote system. A.6.2 The problem A request for remote command execution contains, among others, the command to be executed, and a user and group id. By default, the rexd server believes everything that the client sends it. An intruder can exploit the service to execute commands as any user (except perhaps root). The typical rexd server has no protection against abuse: most implementations have no provision for access control, nor do they require that the client uses a privileged network port. A.6.3 Fix Disable the rexd service. Usually this is accomplished by editing the inetd.conf file, and by sending a HUP signal to the inetd process. Some rexd implementations can be configured to use a more secure protocol. Consult your manual pages for details. A.6.4 See also 1) CERT advisory CA-92:05.AIX.REXD.Daemon.vulnerability ftp://ftp.auscert.org.au/pub/cert/cert_advisories/CA-92:05* --------------------------------------------------------------------------- A.7 Remote shell access A.7.1 The Problem When the remote login/remote shell service trusts every host on the network, a malicious superuser on an arbitrary host can gain access as any user (except perhaps root). Once inside, the intruder can replace system programs or configuration files (such as the password file) and take over the machine. In addition, there are guest or administrative accounts that might not have passwords protecting the account, which allows anyone to remotely login as that user and gain access to the host. A.7.2 Fix Remove the wildcard (+) from the /etc/hosts.equiv file. Be careful with the use of the -@group netgroup feature, as there are many incorrect implementations. Delete or disable any accounts without a password from the system or NIS password file. A.7.3 Other tips Give system accounts such as bin and daemon a non-functional shell (such as /bin/false) and put them in the /etc/ftpusers file so they cannot use ftp. A.7.4 See also 1) AUSCERT's UNIX Security Checklist (sections 2.3 and 2.4) 2) Wietse Venema's logdaemon package, includes replacements for rsh and rlogin daemons. By default these versions do not accept wild cards in host.equiv or .rhost files. They also have an option to disable user .rhost files. logdaemon is available via anonymous ftp from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/logdaemon* ----------------------------------------------------------------------------- A.8 Sendmail vulnerabilities A.8.1 The Problem With almost every sendmail version that was built before February 1995, a malicious user can gain unauthorized privileges by exploiting newlines in command-line arguments or in the process environment. Intruders need to have access to an account on your system to exploit this problem. In addition, pre-8.6.10 versions of sendmail that support IDENT (RFC 1413) functionality have a problem that could allow an intruder to gain unauthorized access to your system remotely (that is, without having access to an account on the system). A.8.2 Fix Ensure that you are running the most recent version of sendmail. A.8.3 See also 1) AUSCERT's UNIX Security Checklist (section 2.13) 2) CERT advisory CA-95:05.sendmail.vulnerabilities ftp://ftp.auscert.org.au/pub/cert/cert_advisories/CA-95:05* ----------------------------------------------------------------------------- A.9 TFTP file access A.9.1 Background The TFTP (trivial file transfer protocol) service provides remote access to files, without asking for a password. It is typically used for the initialization of diskless computers, of X terminals, or of other dedicated hardware. A.9.2 The problem When the TFTP daemon does not limit access to specific files or hosts, a remote intruder can use the service to obtain copies of the password file or of other system or user files, or to remotely overwrite files. A.9.3 Fix Restrict TFTP access to only limited subtree of the file system. Consult your tftpd manual pages for details. When no access restriction is possible, restrict TFTP access by using a tcp wrapper. A.9.4 See also 1) AUSCERT's UNIX Security Checklist (section 2.9) 2) AUSCERT Advisory SA-93.05.tftp.Attacks: ftp://ftp.auscert.org.au/pub/auscert/auscert-advisory/SA-93.05.tftp.Attacks 3) CERT advisories CA-91:18.Active.Internet.tftp.Attacks CA-91:19.AIX.TFTP.daemon.vulnerability ftp://ftp.auscert.org.au/pub/cert/cert_advisories/{CA-91:18*,CA-91:19*} 4) If your version of tftp does not have a chroot option (which would allow you to limit access to a directory subtree) then you can use the chrootuid program to provide this functionality. It is available from: ftp://ftp.auscert.org.au/pub/mirrors/ftp.win.tue.nl/chrootuid* ---------------------------------------------------------------------------- A.10 X server access A.10.1 Background The X Window system implements an environment where applications use the network to interact with a user workstation's display, keyboard and mouse. There are two classes of programs: The X server: the program that manages the user's workstation display and input devices. X clients: the applications that run on the user's workstation or elsewhere in the network. A.10.2 The problem When the X server permits access from arbitrary hosts on the network, a remote intruder can connect to the X server and: Read the user's keyboard, including any passwords that the user types, Read everything that is sent to the screen, Write arbitrary information to the screen, Start or terminate arbitrary applications, Take control of the user's session. A.10.3 Fix Remove all instances of the xhost + command from the system-wide Xsession file, from user .xsession files, and from any application programs or shell scripts that use the X window system. A.10.4 Other tips Use the X magic cookie mechanism or equivalent. With logins under control of xdm, you turn on authentication by editing the xdm-config file and setting the DisplayManager*authorize attribute to true. When granting access to the screen from another machine, use the xauth command in preference to the xhost command. A.10.5 See also 1) AUSCERT's UNIX Security Checklist (section 8) ---------------------------------------------------------------------------- A.11 WU-FTPD Vulnerability (This may not be listed in the pre-release documentation version) A.11.1 Background The wuarchive FTPD daemon (or WU-FTPD) is a highly modified version (and significantly larger) version of FTPD that provides extra logging, limited remote command support, and other features to the standard BSD version of FTPD. The additional code adds greatly to the complexity, and multiple significant software bugs have been found in it. A.11.2 The problem There is a race condition in the code, as well as a bug in the SITE EXEC command, that allows anyone (remote or local) root access on a host running a vulnerable FTPD daemon. Support for anonymous FTP is not required to exploit this vulnerability. A.11.3 Fix Don't use extended or modified FTPD daemons unless they are necessary - vendors code is typically more stable and secure. Upgrade to a more recent version of WU-FTPD; it can be found at the wuarchive ftp site. Restrict FTP access by using a tcp wrapper. A.11.4 See also: 1) AUSCERT's UNIX Security Checklist (section 3) 2) CERT Advisory 93:06.wuarchive.ftpd.vulnerability and CERT Advisory 94:07.wuarchive.ftpd.trojan.horse ftp://ftp.auscert.org.au/pub/cert/cert_advisories/{CA-93:06*,CA-94:07*} ---------------------------------------------------------------------------- AUSCERT wishes to thank Wietse Venema and Dan Farmer, the writers of SATAN, as well as CIAC, DFN-CERT and CERT for their contributions to this advisory. ---------------------------------------------------------------------------- If you believe that your system has been compromised, contact AUSCERT or your representative in FIRST (Forum of Incident Response and Security Teams). AUSCERT is the Australian Computer Emergency Response Team, funded by the Australian Academic Research Network (AARNet) for its members. It is located at The University of Queensland within the Prentice Centre. AUSCERT is a full member of the Forum of Incident Response and Security Teams (FIRST). AUSCERT maintains an anonymous FTP service which is found on: ftp://ftp.auscert.org.au. This archive contains past SERT and AUSCERT Advisories, and other computer security information. AUSCERT also maintains a World Wide Web service which is found on: http://www.auscert.org.au. Internet Email: auscert@auscert.org.au Facsimile: (07) 365 4477 Telephone: (07) 365 4417 (International: +61 7 365 4417) AUSCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for emergencies. Postal: Australian Computer Emergency Response Team c/- Prentice Centre The University of Queensland Brisbane Qld. 4072. AUSTRALIA