_______________________________________________________________________________ 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 is an issue for a given site or system, some issues may be be addressed with the following steps and configuration, which are documented in the manual pages, xhost(1), xmd(1), Xsgi(1), and xauth(1). Additionally, it is highly recommended to read the "X Window System System Administrator's Guide", O'Reilly Vol. 8. from O'Reilly & Associates, ISBN 0-937175-83-8. 1) Become root. % /bin/su - Password: # 2) Edit the file /usr/lib/X11/xdm/Xservers and add the line below. Normally there is only 1 line, but for TKO, be sure this is added for each Xserver. add option '-shmnumclients 0' 3) Save file. 4) Edit the /usr/lib/X11/xdm/xdm-config and make the following change. DisplayManager*authorize: off to DisplayManager*authorize: on 5) Save the file. 6) Edit the file /usr/lib/X11/xdm/Xsession.dt (or Xsession if not using the IndigoMagic desktop) and make the following change. # Gives anyone on any host access to this display /usr/bin/X11/xhost + to # restrict access to this host /usr/bin/X11/xhost - 7) Save the file. 8) Remove any 'xhost +' from the files /usr/lib/X11/xdm/Xsession* 9) Remove any 'xhost +' from users private .xsession files 10) Remove any /etc/X0.hosts or /etc/X.hosts files. 11) Ensure the proper permissions and ownership on the following important X configuration files. Use the chown and chmod commands to adjust accordingly. Permissions owner group file -r--r--r-- root sys /usr/lib/X11/xdm/Xservers -rwxr-xr-x root sys /usr/lib/X11/xdm/Xlogin -rwxr-xr-x root sys /usr/lib/X11/xdm/Xreset -rwxr-xr-x root sys /usr/lib/X11/xdm/Xstartup -rwxr-xr-x root sys /usr/lib/X11/xdm/Xstartup-remote -r--r--r-- root sys /usr/lib/X11/xdm/xdm-config -rwxr-xr-x root sys /usr/bin/X11/X lrwxr-xr-x root sys /X11/Xsgi -rwxr-xr-x root sys /usr/bin/X11/xdm -rwxr-xr-x root sys /usr/bin/X11/xauth -rwxr-xr-x root sys /usr/bin/X11/xhost 12) Restart the graphics system. # /usr/gfx/stopgfx; /usr/gfx/startgfx & K. NTP vulnerabilities Silicon Graphics Incorporated does not provide or support NTP. --------------------------- -- SGI Patch Information -- --------------------------- When an IRIX security vulnerability is found, SGI will investigate the vulnerability and may generate a patch. Patches generated specially for security-related issues are freely available to all requesting customers. IRIX 4.x patches come as tar-bundled binaries and documentation that must be manually installed. Installation instructions are provided with the tar-bundle. For IRIX 5.1 and 5.1.x there are no security patches available. Upgrading to 5.2 or 5.3 is suggested. Patches provided for IRIX 5.2, 5.3 and 6.x are inst images and require a patch aware /usr/sbin/inst program. The stock IRIX 5.2 /usr/sbin/inst program is not patch-aware and must be updated. Patch 84 provides a patch aware inst program for IRIX 5.2. Security patches can be found on SGI anonymous ftp servers: ftp.sgi.com:~ftp/patches or sgigate.sgi.com:~ftp/patches *NOTE*: If a particular file is not found on one, please check the other site. For each security patch a file containing chksum and PGP information for that patch has been generated by the SGI Customer Security Coordinator. The SGI Security Coordinator Public key can be found at: ftp.sgi.com:~ftp/security/agent99.pgp.key.asc or sgigate.sgi.com:~ftp/security/agent99.pgp.key.asc For key fingerprint verification of the above, call +1-415-390-2965. ----------------------------- -- SGI Security Advisories -- ----------------------------- SGI reports security vulnerabilities to the SGI community via Silicon Graphics Incorporated Security Advisories. This document is one such document. An archive of these documents can be found on SGI anonymous ftp servers: ftp.sgi.com:~ftp/security or sgigate.sgi.com:~ftp/security *NOTE*: If a particular file is not found on one, please check the other site. All Security Advisories are PGP digitally signed by the SGI Customer Security Coordinator. The SGI Security Coordinator Public key can be found at: ftp.sgi.com:~ftp/security/agent99.pgp.key.asc or sgigate.sgi.com:~ftp/security/agent99.pgp.key.asc For key fingerprint verification of the above, call +1-415-390-2965. -------------------------- -- Other security tools -- -------------------------- The following tools are publicly available via ftp and could potentially improve a site's security. They are documented here for information only and are not provided, endorsed or supported by SGI. COPS and ISS are programs that check for vulnerabilities and configuration weaknesses. CERT advisory CA-93:14 and CA-93:14.README contain information about ISS. COPS is available from: ftp://info.cert.org:/pub/tools/cops/* ISS is available from: ftp://ftp.uu.net:/usenet/comp.sources.misc/volume39/iss The TCP wrappers system can provide access control and flexible logging for most network services. With proper configuration and use, potential network attacks can be prevent and/or detected. TCP wrappers is available from: ftp://info.cert.org:/pub/tools/tcp_wrappers/* The Swatch log file monitor identifies patterns in log file entries and attempts to associate entries with specific actions. Swatch software is available from: ftp://ee.stanford.edu:/pub/sources/swatch.tar.Z The Rscan program by Nate Sammons checks for many common IRIX-specific security bugs and problems. Rscan is available from: ftp://ftp.vis.colostate.edu/pub/rscan The Courtney package monitors the network and identifies the source machines of potential SATAN probes/attacks. Using a second package, tcpdump, Courtney counts the number of new services requests a machine originates within a certain time period. To Courtney, excessive service requests from a particular machine could indicate it as a potential SATAN probe/attacking host. Courtney software is available from: ftp://ciac.llnl.gov/pub/ciac/sectools/unix/courtney.tar.Z tcpdump software is available from: ftp://ftp.ee.lbl.gov/tcpdump-3.0.tar.Z *Note: the Courtney program requires a correction in order to run on IRIX. The file print-arp.c uses ETHERTYPE_ID which is undefined in IRIX. In places where it is referenced, it needs to be changed to look like: if ((pro != ETHERTYPE_IP #ifdef ETHERTYPE_TRAIL && pro != ETHERTYPE_TRAIL #endif ----------------------------------- -- Reporting SGI Vulnerabilities -- -- Further Information/Contacts -- ----------------------------------- For obtaining security information, patches or assistance, please contact your SGI support provider. If there are questions about this document, email can be sent to: cse-security-alert@csd.sgi.com For reporting *NEW* SGI security issues, email can be sent to: security-alert@sgi.com Please use these aliases wisely. Excessive unnecessary traffic can hinder problem assistance. Do not include the aliases in CC: lists without prudent consideration.