TUCoPS :: General Information :: ciacf020.txt

Satan

            _____________________________________________________
                       The U.S. Department of Energy
                    Computer Incident Advisory Capability
                           ___  __ __    _     ___
                          /       |     /_\   /
                          \___  __|__  /   \  \___
            _____________________________________________________

                             INFORMATION BULLETIN

             Security Administrator Tool for Analyzing Networks
                                  (SATAN)


April 5, 1995 1400 PDT                                           Number F-20
_____________________________________________________________________________

PROBLEM:      Public release of SATAN.
PLATFORMS:    Any IP machine connected to the network.
DAMAGE:       Each IP address for a given subdomain is systematically
              scanned for security weaknesses.
SOLUTION:     Install patches and properly configure systems and firewalls.
_____________________________________________________________________________

VULNERABILITY SATAN has been widely publicized in the national media and 
ASSESSMENT:   on various Internet forums. The software is public available
              as of 5 April 95, 14:00 GMT.
_____________________________________________________________________________
 
    Information about Security Administrator Tool for Analyzing Networks

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.

CIAC recently released CIAC NOTES 07a article (April 5, 1995) that is
devoted to SATAN. The article was based on beta-releases of SATAN and
is applicable to the current version 1.0 release of SATAN. There were
no major operational changes between the latest beta release and the
current version 1.0 public release. The CIAC NOTES article is added as
an appendix and can also be obtained from our ciac server at:

   ftp://ciac.llnl.gov/pub/ciac/notes/notes07a.txt
   http://ciac.llnl.gov/ciac/notes/Notes07a.shtml

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.

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
   ftp://ciac.llnl.gov/pub/ciac/sectools/unix.

CIAC has also make available the current release of SATAN at

   http://ciac/llnl.gov/ciac/ToolsUnixNetMon.html#Satan
   ftp://ciac.llnl.gov/pub/ciac/sectools/unix.  

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.

------------------------------------------------------------------------------
             U.S. DOE's Computer Incident Advisory Capability
           ___  __ __    _     ___           __  __ __   __   __
          /       |     /_\   /       |\ |  /  \   |    |_   /_
          \___  __|__  /   \  \___    | \|  \__/   |    |__  __/

Number 95-07A                                                 April 5, 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 with IP
addresses.  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 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 the security of the
Internet. 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 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.

Unprivileged 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 file system, 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
file systems 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 (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. 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.

--------
End of CIAC Notes Number 95-07a 95_4_5
------------------------------------------------------------------------------
CIAC is the computer security incident response team for the U.S.
Department of Energy.  Services are available free of charge to DOE and DOE
contractors.
 
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 404-555-1212 x36
subscribe ciac-bulletin O'Hara, Scarlett 404-555-1212 x36
 
You will receive an acknowledgment containing address and initial PIN, and
information on how to change either of them, cancel your subscription, or get
help.
_____________________________________________________________________________
 
 
PLEASE NOTE: Many users outside of the DOE and ESnet computing communities
receive CIAC bulletins. If you are not part of these communities, please
contact your agency's response team to report incidents. Your agency's team
will coordinate with CIAC. The Forum of Incident Response and Security Teams
(FIRST) is a world-wide organization. A list of FIRST member organizations
and their constituencies can be obtained by sending E-mail to
first-request@first.org with an empty subject line and a message body
containing the line: send first-contacts.
 
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,
expressed or implied, or assumes any legal liability or responsibility for
the accuracy, completeness, or usefulness of any information, 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 nor the University of California, and
shall not be used for advertising or product endorsement purposes.
 
_____________________________________________________________________________


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH