CIAC Notes

Number 95-07B:April 7, 1995
ATTENTION: CIAC is available 24-hours a day via its two skypage numbers. To use this service, dial 1-800-759-7243. The PIN numbers are: 8550070 (for the CIAC duty person) and 8550074 (for the CIAC manager). Please keep these numbers handy.
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.

Released on 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.

SATAN is guaranteed to have a large impact on Internet security. It 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 1.0. 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.

FTP vulnerabilities

The enhanced FTP daemon, wuarchive, has several vulnerabilities not present in the standard FTP daemon. If WU-FTPD is being used, make sure and get the latest version.

NFS export to unprivileged programs

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 export via 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. For System V based systems, a similar tool has been written by Venema which is a replacement for rpcbind.

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

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.

REXD access

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

TFTP file access

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.

Sendmail vulnerabilities

Sendmail has a variety of well documented bugs, particularly on version of sendmail prior to 8.6.10. Make sure that the latest version of sendmail is being used, and that all patches have been installed.

Remote shell access

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 .

Unrestricted NFS export

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.

Unrestricted X server access

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

Unrestricted modems

When a dialout modem is placed on a TCP port, it is possible for an outside user to dial out with that modem. Modems do not need to be on a TCP port, and will do just fine in a variety of other places, such as a serial port.

For more information on securing anonymous FTP and other information servers, see the CIAC Document CIAC-2308 R.2

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. Verify that the MD5 checksum of the compressed tar file (of Courtney 1.2) has a value of 3257009164eaf10d1e3ae4a7de102f03.

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. The Network Intrusion Detector (NID) provides a suite of security tools for detecting and analyzing network intrusion.

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:

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 and anonymous FTP.

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 W. 404-555-1212 x36
You will receive an acknowledgment containing address, initial PIN, and information on how to change either of them, cancel your subscription, or get help. To subscribe an address which is a distribution list, first subscribe the person responsible for your distribution list. You will receive an acknowledgment (as described above). Change the address to the distribution list by sending a second E-mail request. As the body of this message, send the following request, substituting valid information for list-name, PIN, and address of the distribution list:.

Send E-mail to ciac-listproc@llnl.gov: 

	set list-name  address  PIN   distribution_list_address
e.g., 
        set ciac-notes address 001860 rE-mailer@tara.georgia.orb
To be removed from this mailing list, send the following request: 
        unsubscribe  list-name
For more information, send the following request: 
        help
If you have any questions about this list, you may contact the list's owner: listmanager@cheetah.llnl.gov.

This document was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the University of California nor any of their employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by the United States Government or the University of California. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or the University of California, and shall not be used for advertising or product endorsement purposes.
End of CIAC Notes Number 95-07 95_3_29