________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
INFORMATION BULLETIN
Protecting IBM AIX Systems Against SATAN
May 8, 1995 1400 PDT Number F-23
_____________________________________________________________________
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 bulletins focuses on SATAN's impact on IBM AIX
Systems.
DAMAGE: Anyone running SATAN can gain vulnerability information
that can be exploited with other tools to gain privileged
access.
SOLUTION: Update all IBM AIX 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 IBM AIX Vulnerabilities
CIAC has obtained information from IBM describing the specific patches
for the vulnerabilities SATAN will scan for. Specific patch details
are provided below.
[BEGINNING OF IBM AIX BULLETIN]
...........................................................................
Preparing your AIX System for SATAN
AIX Security Response Team
security@austin.ibm.com
...........................................................................
I. Purpose of this document
II. AIX vulnerabilities probed by SATAN
1. NFS export to unprivileged programs
2. NFS export via portmapper
3. Unrestricted NFS export
4. NIS password file access
5. rexd access
6. Sendmail vulnerabilities
7. TFTP file access
8. Remote shell access
9. Unrestricted X server access
10. Writable FTP home directory
11. wu-ftpd vulnerability
III. More information on AIX security
IV. More information on internet security topics
V. CERT advisory on SATAN
...........................................................................
I. Purpose of this document
...........................................................................
Everyone is becoming increasingly aware of computer security
issues. No one wants to lose valuable information to unwanted
intruders. The SATAN tool was developed to help system administrators
secure all computers on their networks. The danger exists that this
tool could be used for unlawful purposes.
We want to help AIX users secure their systems so SATAN will not
cause any problems. This document is intended to help AIX users
understand each of the vulnerabilities probed by SATAN and learn what
they can do to secure their systems in each of these areas. Many
books and articles have been written on computer security
configuration issues and we will refer you to these articles
when appropriate.
...........................................................................
II. AIX vulnerabilities probed by SATAN
...........................................................................
...........................................................................
1. NFS export to unprivileged programs
...........................................................................
If the nfs mount daemon, rpc.mountd, is started with the -n
flag it allows mount requests to come from non-privileged ports.
This is used to allow some older versions of NFS to perform mounts.
It should not be used. The AIX default is to not use the -n flag.
For additional security use the nfso utility to turn on kernel port
checking. The command would be:
nfso -o nfs_portmon=1 (in AIX version 3 )
nfso -o portcheck=1 (in AIX version 4 )
The default in AIX is to NOT do kernel portchecking.
...........................................................................
2. NFS export via portmapper
...........................................................................
Access to filesystems via portmapper is disabled by default in
recent versions of AIX. To make sure you have a later version of
portmapper that fixes this problem, check to make sure your machine
has the fix for APAR IX32328. That fix has been included in PTFS
U419992 U419994 U419995.
Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U419992 U419994 U419995
...........................................................................
3. Unrestricted NFS export
...........................................................................
Entering a directory or filesystem in the /etc/export list without
specifying an access list allows any host who's IP address can be
resolved to mount the directory. This is not secure. The access list
should be specified when exporting filesystem objects.
Exports specifying root access or read/write access also are inherently
lower security and should be implemented with caution.
...........................................................................
4. NIS password file access
...........................................................................
The ability to view encrypted passwords when NIS is being used
and the ability to exploit the information can be curtailed and
to some extent prevented in a number of ways.
A) use a /var/yp/securenets file to restrict the NIS services to
trusted networks. (see the notes on securenets below).
B) Make the NIS domain name hard to guess and non-obvious. Employee
turnover or other security concerns may require domain renaming.
(use the chypdom command or smit chypdom to change domain names and
move the /var/yp/<domain_name> directory to the new name)
C) Require users to use non-trivial passwords.
Use of the /var/yp/securenets file:
The implementation of ypserv and ypxfrd that utilize the
securenets file was shipped in response to APAR ix32328
Some PTF's that contain that fix are:
U419992 U419994 and U419995.
Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U419992 U419994 U419995
Both the "ypserv" and "ypxfrd" use a /var/yp/securenets
file and, if present, only responds to IP addresses in the
range given. This file is only read when the daemons (both
ypserv & ypxfrd) start. To get a change in /var/yp/securenets
to take effect, one must kill and restart the daemons.
The format of the file is one or more lines of:
netmask netaddr
e.g.
255.255.0.0 128.30.0.0
255.255.255.0 128.311.10.0
In the 2nd example, the netmask is 255.255.255.0
and the network address is 128.311.10.0 . This
setup will only allow the ypserv to respond to
those IP addresses which are within the subnet
128.311.10 range.
An additional NIS security note is that allowing ypset to
reset ypbind binding lowers security. ypbind daemons
shipped in the fix for APAR IX43595 (in PTF U431006)
disallow ypset's as their default behavior and this is
strongly recommended.
Use the following aix cmd to determine if you have applied this ptf:
$ lslpp -al U431006
...........................................................................
5. rexd access
...........................................................................
The rexd server allows users to execute commands on remote servers
in an environment similar to that of the local system. No validation
of identity or access permission is performed. This behavior leads
many people to believe that the use of rexd is a security vulnerability.
There are currently no known defects in the rpc.rexd command which
adversely affect the security of the system. rpc.rexd is contained in
the bosnet.nfs.obj.client subsystem. The most recent PTF for that
subsystem as of the writing of this document is U436781.
Use the following aix cmd to determine if you have applied this ptf:
$ lslpp -al U436781
The lack of authentication of the identity of the invoker may present
a security exposure in an untrustworthy environment. You should weigh
the risks of a security exposure against the functionality provided when
you consider enabling this service.
The problems with rexd are inherent in the design of the server and
cannot be corrected easily. The security problems can be limited by
careful use of NFS exports on the client system and by disabling rexd
on the server.
IBM issued CA-92:05 on March 5, 1992 describing a problem with the
initial configuration of rexd on AIX 3.1 and AIX 3.2 systems. APAR
IX21353 was opened to correct this problem. The problem corrected by
this APAR no longer exists in AIX 3.2.5 or AIX 4.1.
In AIX 3.2.5 and 4.1 rexd is disabled by default when shipped.
...........................................................................
6. Sendmail vulnerabilities
...........................................................................
All AIX versions of /usr/sbin/sendmail are vulnerable to some of the
attacks described in CA-95:05. The official APARs resolving ALL known
AIX sendmail vulnerabilities are IX49257 (version 3.2) and IX49604
(version 4.1).
AIX users should obtain the emergency patch from Internet
ftp site software.watson.ibm.com. The file is located in
/pub/aix/sendmail/sendmail.tar.Z in compressed tar format.
Please follow the installation instructions in the sendmail.readme
file located in this same directory.
Currently, AIX versions 3.2 and 4.1 are based on sendmail version
5.64. Although this is an old version of sendmail, all known
sendmail security bugs are fixed by the emergency patch mentioned
previously.
If you permit automatic mail forwarding or programs that accept
mail messages, please be sure there is no way for these programs
to create a shell or send commands. This type of configuration can
create a security hole that could be exploited by an unfriendly user.
...........................................................................
7. TFTP file access
...........................................................................
The tftpd server allows users to retrieve files without requiring an
account on the remote server. Tftpd is commonly used by diskless systems
and X-stations as well. Tftp does not require the use of a user name or
password and therefore may grant access to system data when the identity
of the requestor has not been established. This may allow unknown users
to acquire restricted data or to modify user files.
There are currently no known defects in tftpd which adversely affect the
security of the system. The tftpd command is contained in the
bosnet.tcpip.obj.client subsystem. The most recent PTF for that subsystem
as of the writing of this document is U435114.
The lack of any authentication or identification of the requestor should
be considered when configuring tftpd. The tftp service may be restricted
using the /etc/tftpaccess.ctl file. This file is documented in
InfoExplorer under the tftpd command. This function was added to AIX v3.1
by APAR IX22628 and is available in the 2014 level PTF.
Tftp should be configured in /etc/inetd.conf to run as the user "nobody".
The following line is an example of how to do this.
tftp dgram udp wait nobody /etc/tftpd tftpd -n
THIS EXAMPLE WILL ALLOW REMOTE USERS TO WRITE FILES ON THE LOCAL SYSTEM.
If you have no requirement for granting write permission to remote users
you should consider removing the "-n" flag from the command line given
above.
The user "nobody" should own no files or directories on the system. The
only files or directories which the user "nobody" should be able to read
are those with read or write (and execute for directories) permission to
"other". Refer to the chmod command in InfoExplorer for details on how to
manage file and directory permissions. By properly restricting access to
"other", you will effectively limit the files and directories which tftpd
may access and modify.
IBM released CERT advisory CA:91-19 on October 17, 1991 for the tftpd
daemon. The vulnerability described in that advisory is corrected in all
releases of AIX v3.2 and AIX v4.
...........................................................................
8. Remote shell access
...........................................................................
The rsh and rlogin commands are used to establish sessions on remote
servers. Both commands operate in a similar manner from an access
perspective. The file /etc/hosts.equiv or a .rhosts file in the user's
home directory may be consulted to determine if access is granted. When
access is not automatically granted for the rlogin command the remote user
is prompted for a password.
The rshd server has had one security related defect. APAR IX45182
corrected a defect in which the "-l" option (used to control operation of
the server) did not work properly. This APAR was first delivered in PTF
U432655. This PTF should be applied to any system which has been
configured according to the instructions given below. This problem does
not exist on any release of AIX v4.
The rlogind server has had one significant security related defect. APARs
IX44254 and IX44367 corrected a defect in which any network user was able
to gain access to the remote system as any user. These APARs were first
delivered in PTFs U431620 and U431622 respectively. Both of these PTFs or
their superceding PTFs should be installed on all systems. This problem
does not exist on any release of AIX v4.
Two significant enhancements have been made to the rshd server. APAR
IX45701 added a facility for restricting use of rshd and rexecd on a user
by user basis. This feature may be useful for critical system accounts
which might be subject to attack via a network connection. This APAR was
first delivered in PTF U434068. APAR IX48235 added additional auditing
capability. This feature may be useful when connecting to unsecure
networks or when you are interested in monitoring rshd usage. A USER_Login
audit event will be created for each rshd invocation. This may be used in
conjunction with the TCPIP_access event to determine local user and remote
hostname for each rshd and rexecd. As of the writing of this document this
APAR has not been packaged into a PTF.
Both rshd and rlogind are subject to security violations related to
use of the /etc/hosts.equiv and $HOME/.rhosts files. This exposure can
be removed by adding the "-l" flag to the rshd and rlogind command
lines in /etc/inetd.conf. The following two lines are an example of how
you might do this.
shell stream tcp nowait root /etc/rshd rshd -l
login stream tcp nowait root /etc/rlogind rlogind -l
If you do not wish to grant remote network access to your system, you may
disable this facility entirely with lines similar to the following.
#shell stream tcp nowait root /etc/rshd rshd
#login stream tcp nowait root /etc/rlogind rlogind
Please refer to InfoExplorer for additional information on configuring
the /etc/inetd.conf file and the inetd daemon.
Should you choose to enable rshd and/or rlogind, the use of the
/etc/hosts.equiv and $HOME/.rhosts files creates a dependency on the
information in those files and the information which the servers use being
accurate. Errors in either file or spoofing of host addresses or names
are common causes of security exposures. When the network is not secure
or trustworthy, consider disabling these services for some or all users or
enabling the auditing subsystem to track possible attacks. You may also
wish to consider use of a firewall or some other form of packet filter to
restrict access to trustworthy hosts or networks.
InfoExplorer describes the proper configuration of the /etc/hosts.equiv
file. As a general rule, grant access to specific users and specific
hosts. You should monitor the existence of .rhosts files and insure that
users are educated about their proper use.
The telnet service may be more appropriate in an unsecured network
environment as it does not support the pre-authentication of users.
CERT advisory CA-94:09 was released on May 23, 1994 describing the security
exposure in the rlogin service.
Use the following aix cmd to determine if you have applied one of these ptfs:
$ lslpp -al U43xxxx
...........................................................................
9. Unrestricted X server access
...........................................................................
In 1993 CERT issued advisory CA-93:17 which documented a xterm vulnerability
in X11R5 and earlier versions of X11. This problem was resolved by the
following apars:
aixterm X11r4 : ix34738 - resolved by U417488 and U419246
aixterm X11r5 : ix40275 - resolved by ptf U425631
xterm X11r4 : ix40279 - resolved by ptf U425255 and U425228
xterm X11r5 : resolved by U493250 (3.2.5 Gold)
Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U4xxxxx
If you are using AIX 3.2, please make sure you have all these
ptfs applied to avoid potential security problems. These fixes
are shipped as part of the GOLD version of AIX 4.1. Because of X11's design,
the client/server can be accessed by any other host on the network. If
you are on the Internet, your display can be accessed by any machine in
the world. X11 security issues for AIX are similar to the X11 security problems
facing other X11 vendors. It is difficult to make X completely secure.
However, there are access control mechanisms which can be put in place
to help make your environment more secure. You should never use the
"xhost +" cmd because this will enable any remote user to read/write
screen information. Please remove all "xhost +" cmds from any file
or program on your system. A useful tool for limiting X access, please
see the /usr/bin/xauth
The best source of information on securing X is in : O'Reilly & Associates,Inc.
"X Window System Adminstrator's Guide". Specifically chapter 4 which goes into
detail about X security. The discussion in this chapter applies to the AIX
environment. In additon, the Common Desktop Enviroment (CDE) interface
available on AIX 4.1 uses XDMCP protocol discussed in this chapter.
...........................................................................
10. Writable FTP home directory
...........................................................................
In 1992, CERT issued advisory CA-92:09 about an AIX Anonymous FTP
Vulnerability. This problem was resolved by apar ix23944, which
was included in the GOLD release of AIX 3.2. Thus, AIX 3.2 and 4.1 systems
are not vulnerable to this problem. The original problem was discovered
on AIX 3.1. If you are running AIX 3.1, please update to the latest
release of 3.1, which resolves this problem.
The following information can be very helpful:
- The ftpd man page has explicit instructions for securely
configuring your anonymous FTP user and subtree.
- The /usr/lpp/samples/tcpip/anon.ftp file can be used to securely
set up your anonymous account. (/usr/samples/tcpip/anon.ftp in AIX 4.1)
- The CERT tip found at ftp://info.cert.org/tech_tips/anonymous_ftp
contains applicable information.
...........................................................................
11. wu-ftpd vulnerability
...........................................................................
This problem only affects users running the wuarchive-ftpd.
If you do not have this modified version of ftpd, then you are
not vulnerable to this specific attack. If you are running the
wuarchive-ftpd, and your version is dated prior to April 8, 1993,
please take corrective action or remove this daemon.
You can obtain more information about this service via anonymous ftp
from wuarchive.wustl.edu (128.252.135.4).
This service is NOT distributed with AIX.
...........................................................................
III. More information on AIX security
...........................................................................
We publish an AIX security newsletter that is updated whenever
we have security information that affects AIX users.
To subscribe to the newsletter:
mail -s "subscribe security" aixserv@austin.ibm.com < /dev/null
If you have comments or questions about AIX security, or you
would like to notify us of a potential problem, please send mail
to security@austin.ibm.com.
To order an APAR from IBM in the U.S. call 1-800-237-5511.
APARs may be obtained outside the U.S. by contacting a
local IBM representative.
[End of IBM AIX Bulletin]
CIAC recently released CIAC NOTES 07 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. 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.
CIAC has also make available the current release of SATAN
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.
Refer to CIAC Notes 7 for an indepth look at SATAN.
________________________________________________________________________________
CIAC wishes to thank Randy S. Greenberg of IBM for their response to this
problem.
________________________________________________________________________________
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.
For emergencies and off-hour assistance, DOE and DOE contractor sites can contact
CIAC 24-hours a day via an integrated voicemail and SKYPAGE number. To use this
service, dial 1-510-422-8193 or 1-800-759-7243 (SKYPAGE). The primary SKYPAGE PIN
number, 8550070 is for the CIAC duty person. A second PIN, 8550074 is for the CIAC
Project Leader. CIAC's FAX number is 510-423-8002, and the STU-III number is 510-
423-2604. Send E-mail to ciac@llnl.gov.
Previous CIAC notices, anti-virus software, and other information are available on
the CIAC Bulletin Board and the CIAC Anonymous FTP server. The CIAC Bulletin Board
is accessed at 1200 or 2400 baud at 510-423-4753 and 9600 baud at 510-423-3331. The
CIAC Anonymous FTP server is available on the Internet at ciac.llnl.gov (IP address
128.115.19.53).
CIAC has several self-subscribing mailing lists for electronic publications: CIAC-
BULLETIN, CIAC-NOTES , SPI-ANNOUNCE, and SPI-NOTES.To subscribe (add yourself) to
one of our mailing lists, send requests of the following form to ciac-
listproc@llnl.gov:
subscribe list-name LastName, FirstName PhoneNumber
For additional information or assistance, please contact CIAC:
Voice: 510-422-8193
FAX: 510-423-8002
STU-III: 510-423-2604
E-mail: ciac@llnl.gov
ATTENTION!! CIAC now has a web server at http://ciac.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.
CIAC BULLETINS ISSUED IN FY95 (Previous bulletins available from CIAC)
(F-01) SGI IRIX serial_ports Vulnerability
(F-02) Summary of HP Security Bulletins
(F-03) Restricted Distribution
(F-04) Security Vulnerabilities in DECnet/OSI for OpenVMS
(F-05) SCO Unix at, login, prwarn, sadc, and pt_chmod
Patches Available
(F-06) Novell UnixWare sadc, urestore, and suid_exec Vulnerabilities
(F-07) New and Revised HP Bulletins
(F-08) Internet Address Spoofing and Hijacked Session Attacks
(F-09) Unix /bin/mail Vulnerabilities
(F-10) HP-UX Remote Watch
(F-11) Unix NCSA httpd Vulnerability
(F-12) Kerberos Telnet Encryption Vulnerability
(F-13) Unix sendmail vulnerabilities
(F-14) HP-UX Malicious Code Sequences
(F-15) HP-UX "at" and "cron" vulnerabilities
(F-16) SGI IRIX Desktop Permissions Tool Vulnerability
(F-17) Limited Distribution
(F-18) MPE/iX Vulnerabilities
(F-19) Protecting HP-UX Systems Against SATAN
(F-20) Security Administrator Tool for Analyzing Networks (SATAN)
(F-21) Protecting SUN OS Systems Against SATAN
(F-22) SATAN Password Disclosure
CIAC NOTES ISSUED IN FY1995 (Previous Notes available from CIAC)
04c December 8, 1994
05d January 11, 1995
06 March 22, 1995
07 March 29, 1995
08 April 4, 1995
09 April 24, 1995
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
