💾 Archived View for spam.works › mirrors › textfiles › hacking › satan~1.txt captured on 2023-11-04 at 13:26:07.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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