INFORMATION BULLETIN
INFORMATION BULLETIN
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.
[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/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 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.
Voice: +1 925-422-8193 (7 x 24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@ciac.org
World Wide Web: http://www.ciac.org/
Anonymous FTP: ftp.ciac.org