[104] in Intrusion Detection Systems
CIAC Bulletin F-24: Protecting SGI IRIX Systems Against SATAN
daemon@ATHENA.MIT.EDU (Frank Swift (510-422-1463))
Fri May 12 23:09:43 1995
Date: Fri, 12 May 1995 15:56:23 -0700
To: ids@uow.edu.au, academic-firewalls@net.tamu.edu, firewalls-uk@gbnet.net
From: uncl@llnl.gov (Frank Swift (510-422-1463))
Reply-To: ids@uow.edu.au
Date: Fri, 12 May 1995 10:12:21 -0700
Reply-To: dwsmith@cheetah.llnl.gov
Originator: ciac-bulletin@cheetah.llnl.gov
Sender: ciac-bulletin@cheetah.llnl.gov
Precedence: bulk
From: David Smith <dwsmith@cheetah.llnl.gov>
To: uncl@llnl.gov
Subject: CIAC Bulletin F-24: Protecting SGI IRIX Systems Against SATAN
-----BEGIN PGP SIGNED MESSAGE-----
__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
INFORMATION BULLETIN
Protecting SGI IRIX Systems Against SATAN
May 11, 1995 1300 PDT Number F-24
_______________________________________________________________________________
PROBLEM: SATAN, a tool for scanning Unix systems was released on
April 5. The tools identifies exploitable vulnerabilities,
most of which can be patched.
PLATFORM: This bulletin focuses on SATAN's impact on SGI IRIX
Systems.
DAMAGE: Anyone running SATAN can gain vulnerability information
that can be exploited with other tools to gain privileged
access.
SOLUTION: Update all SGI IRIX systems with the patches identified
below.
AVAILABILITY: All patches are available now.
_______________________________________________________________________________
VULNERABILITY When SATAN was released via the Internet on April 5, it
ASSESSMENT: became available to anyone, including system administrators
and security specialists who protect corporate systems.
It is also available to others who could use it to gain
information about unpatched system vulnerabilities and
then exploit these vulnerabilities with other tools to
gain unauthorized access.
_______________________________________________________________________________
CRITICAL Information for patching SGI IRIX Vulnerabilities
CIAC has obtained information from SGI describing the specific patches for
the vulnerabilities SATAN will scan for. Specific patch details are
provided below.
[BEGINNING OF SGI IRIX BULLETIN]
- -----BEGIN PGP SIGNED MESSAGE-----
________________________________________________________________________________
Silicon Graphics Inc. Security Advisory
Title: Release of SANTA/SATAN tool and SGI specifics
Title: CERT CA-95:06 Security Administrator Tool for Analyzing Networks
Number: 19950401-01-I
Date: April 5, 1995
________________________________________________________________________________
Silicon Graphics provides this information freely to the SGI community
for its consideration, interpretation and implementation. Silicon Graphics
recommends that this information be acted upon as soon as possible.
Silicon Graphics will not be liable for any consequential damages arising
from the use of, or failure to use or use properly, any of the instructions
or information in this Security Advisory.
________________________________________________________________________________
The Silicon Graphics Incorporated Engineering and Customer Support Divisions
have investigated the SATAN program and have completed this document to
assist and inform ALL SGI customers in regards to SATAN issues.
- - --------------------
- - -- What is SATAN? --
- - --------------------
The Security Analysis Network Tool for Administrators/Security Administrator
Tool for Analyzing Networks, also known as SANTA/SATAN, is a graphical
administrator's tool that can remotely probe and analyze potential security
issues on a wide variety of computer platforms. SATAN is scheduled to be
released on April 5, 1995 at 14:00 GMT.
Using the SATAN program, probes can be performed at several levels of
increasing concentration, from light to heavy. The target of the probes
can be on either a specific host, group of hosts or a network of hosts. At
the conclusion of any probe, a complete report of potential security problems
is provided. Each problem is briefly described, along with pointers to
known patches and/or work-arounds. As part of the probe activity, SATAN
also gathers general network information, including overall network topology,
running network services, and types of hardware and software being used.
Of particular note is the "exploratory mode" of SATAN. When probing in
"exploratory mode," SATAN will probe hosts that have not been explicitly
specified. These unspecified hosts are selected based on security problems
found on initially specified hosts. This could result in SATAN probing not
only targeted hosts, but also hosts outside your administrative domain
and could be perceived as an attack. Be aware that unauthorized access to
computer systems may expose you to potential civil liabilities and criminal
penalties.
The design of the SATAN provides for flexible extensibility via perl
scripts. It is expected that many future extensions will be made available
publically and privately for probing and/or exploiting security
vulnerabilities. At this time, the initial version of SATAN does
not actively exploit the vulnerabilities it finds.
Please note that SGI does not provide, support or assist with the use of
SATAN. However, SGI is very interested in investigating all potential
IRIX security vulnerabilities discovered, whether by SATAN or other means.
- - --------------------------------------
- - -- Where can the SATAN program and --
- - -- SATAN documentation be obtained? --
- - --------------------------------------
***** Please note that SGI does not provide, support
or assist with the use of SATAN. *****
SATAN information and documentation is available via WWW browser with:
ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z
http://ciac.llnl.gov/ciac/ToolsUnixNetSec.html#Satan
Or via anonymous ftp site :
ftp.win.tue.nl
in the directory:
/pub/security/satan_doc.tar.Z
Further documents are also available through a mail server provided
by one of the SATAN authors.
Send mail to:
majordomo@wzv.win.tue.nl
and put in one or any combination of following lines in the body (not
the Subject:) of the mail:
get satan mirror-sites
get satan release-plan
get satan description
get satan admin-guide-to-cracking.101
It should be noted that the last document, admin-guide-to-cracking.101,
contains "Improving the Security of Your Site by Breaking Into It," a 1993
paper in which the SATAN authors give their rationale for creating the
program SATAN.
- - ----------------------------------------------------
- - -- SATAN Vulnerabilities Probes and SGI Specifics --
- - ----------------------------------------------------
In any environment, customers themselves must assess the work requirements
and security vulnerabilities of their systems in order to take actions
appropriate to the level of exposure noted in these assessments and all
security issues. A system directly accessible from the Internet, i.e.
not protected by firewalls, is significantly more vulnerable than a system
in a collaborative environment protected from outside access. There is
specific advice on a number of security related topics in the "Advanced Site
and Server Administration Guide," particularly in Chapters 12 and 16, and in
the IRIX on-line manual pages for the programs being examined by SATAN.
In the details provided below, specific IRIX release specifics are mentioned
when possible. When no specific release is indicated, the information
applies to all IRIX releases.
A. Writable ~ftp home directory
The manual page for ftpd(1m) is recommended as the primary reference source
for anonymous ftp service information.
It must be noted that, although the manual page for ftpd(1m) in its
description of how to setup an anonymous ftp service recommends that the
~ftp directory be owned by ftp and be mode 555, sites directly connected to
the Internet should change the ownership of this directory to bin to preclude
an external user modifying the permissions on the home directory.
Additionally, care must be taken to follow the directions in the ftpd(1m)
manual pages in setting up an anonymous ftp account. Anonymous ftp accounts
are intrinsically vulnerable to misuse, so care and constant monitoring are
critical.
B. Unprivileged NFS access
Although the mount daemon (mountd(1m)) permits access from unprivileged ports,
this should be enabled only when specifically required, e.g. when access
from a non-standard system is needed. Systems directly exposed to the Internet
should not export any file systems and should disable mountd by editing
/etc/inetd.conf (/usr/etc/inetd.conf for IRIX 4.x) as according to the manual
page, mountd(1M).
C. Unrestricted NFS export
As shipped from the factory, IRIX does not export any file systems for remote
NFS access. When it is required to export a file system, if possible,
restricting NFS access to specific hosts and users might be considered. These
restrictions can be established by editing /etc/exports in accordance with the
the manual pages, exportfs(1M) and exports(4).
D. NIS password file access
NIS can be very useful in collaborative environments, but it is extremely
vulnerable to a variety of threats. In sites where sensitive information
must be protected, and where such activities as password- cracking or
NIS server-spoofing cannot be prevented through administrative controls,
NIS should not be used for passwords. Such sites could consider the
use of shadow passwords on vulnerable systems to reduce the possibility
of password-cracking. Systems directly exposed to the Internet should
not use NIS and should not expose NIS servers behind the firewall.
E. Portmap forwarding
Systems directly exposed to the Internet should reduce the remotely invocable
services supported to a level necessary to provide the required services.
Generally, such a system should not be providing RPC services via portmap or
rpcbind to the outside world, as these services were designed for collaborative
environments, and do not have strong security protections. At those sites,
where organizational needs require that these systems support RPC services,
portmapper restrictions should be considered. Restrictions such as
- - -a mask,match which restricts access to specified networks, and -v which
logs accesses from unprivileged ports are useful. These arguments are defined
in the /etc/config/portmap.options file as outlined in the manual page,
portmap(1M).
F. tftp file access
As shipped from the factory, tftp is secured with the -s option. However,
the Installation guide and other installation documents will frequently
have this turned off to accomplish a specific task. The manual page for
tftpd and inetd, tftpd(1M) and inetd(1M), are to be referred to for ensuring
the correct use of the -s option. The factory default is
tftp dgram udp wait guest /usr/etc/tftpd tftpd -s \
/usr/local/boot /usr/etc/boot
G. Remote shell (rsh) access
As stated above, systems that are directly accessible (no firewall) to the
Internet should restrict the remotely invocable services on that system to
the absolute minimum necessary to perform the required function(s). As
shipped from the factory, the IRIX operating system environment permits a
fairly wide range of services through inetd(1M). Sites should reduce the
available services by editing /etc/inetd.conf per the manual pages and
refreshing inetd with the new configuration via "killall -HUP inetd".
To remove a service, either comment the service out with a "#" character
as the first character of the line, or remove the service line entirely
from the file. Services left accessible can be configured to improve
security by using certain options. Below, some options to consider are
listed, but the manual pages should be referred to for completeness.
rlogind use '-l' to disable validation using .rhosts files
fingerd use '-l' to log all connections
use '-S' to suppress information about login status,
home directory, and shell
use '-f msg-file' to make it just display that file
rshd use 'a' to verify that all incoming remote host names
and addresses match
use '-l' to disable validation using .rhosts files
use '-L' to log all access attempts to syslog
For standard logins, it is prudent to enhance security with several options
as described in the manual pages for login, login(1).
login set MANDPASS=YES
set SYSLOG=ALL
set LOCKOUT=5
H. Vulnerability in rexd configuration
The Remote Execution daemon, rexd, is an example of a service that is
inappropriate on systems directly exposed to the Internet. The rexd daemon
assumes a collaborative environment in making access control decisions. As
such, the rexd program should be disabled by editing /etc/inetd.conf
(on 5.x, 6.x) or /usr/etc/inetd.con (on 4.x) file as described above and
in the manual pages, rexd(1M). The line below illustrates a disabled
rexd program.
#rexd/1 stream rpc/tcp wait root /usr/etc/rpc.rexd rexd
I. Sendmail vulnerabilities
SGI Security Advisory 19950201-02 addresses sendmail vulnerabilities
recently reported in CERT 95:05. The advisory provides patch information
on obtaining patch 332 that provides a 8.6.10 sendmail program. By connecting
to the SMTP port, SATAN attempts to determine the version of sendmail running
and determine secureness. SATAN's assessment may be incorrect even when the
patch is installed. See the "SGI Patch Information" section below for further
information on obtaining patches.
J. Unrestricted X server access
As factory shipped, IRIX fosters a cooperative X work environment between
workstations by permitting remote systems to access the local X server. In
less friendly environments, this can be considered a vulnerability. If this
THE WORLD IS NOT INTERESTED IN THE STORMS YOU ENCOUNTERED,
BUT WHETHER YOU BROUGHT IN THE SHIP .
\ | /
| 0 0 | Frank Swift L-321 (510)-422-1463
~^~ LLNL 7000 East Avenue ( fax) 423-0913
\O/ Livermore CA 94550-9516_____________uncl@llnl.gov________+
Unclassified Computer Security Lawrence Livermore National Lab
Observing and Reacting to "the Net of a Million Lies"
