364 lines
20 KiB
Plaintext
364 lines
20 KiB
Plaintext
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 |