NASIRC BULLETIN #93-05 October 22, 1993 SGI/IRIX CONFIGURATION VULNERABILITIES =========================================================================== __ __ __ ___ ___ ____ ____ /_/\ /_/| /_/ / _/\ /_/| / __/ \ / __/\ | |\ \| || / \ \ | /\/ | || | /\ \/ | | \/ | ||\ \ || / /\ \ \ \ \ | || |_\/ /\ | | | || \ \|| / /--\ \ \ /\_\\ | || | |\ \ \ | \_/\ |_|/ \_|//_/ \_\/ \/__/ |_|/ |_| \_\/ \___\/ NASA Automated Systems Incident Response Capability =========================================================================== NASIRC has received information indicating that SGI IRIX systems configured with operating system defaults are vulnerable to attack. The auto-installation procedure leaves some default accounts vulnerable to compromise, some files are left world readable, and the default configuration for xhost is vulnerable. This bulletin reminds IRIX system administrators to check various default settings on their systems. OPEN ACCOUNTS Silicon Graphics IRIX machines come with several well-known vendor-supplied user IDs that have no password. This means that anyone who guesses that your machine is an IRIX machine can attempt to login using one of these IDs. (Generally, using telnet to a machine will cause it to display its operating system type and version number.) The IDs that have been seen in the local area are: tutor guest demos lp uucp nuucp 4Dgifts diag (may have superuser privileges) Because of the powerful graphical user interface, IRIX users may be unaware of the vulnerable IDs, or how to protect them. Given any access to the system, attackers can usually find additional exposures that will allow them to gain superuser access. In some cases, a non-privileged account such as guest has been used to copy any publicly readable file, such as the password file, /etc/passwd, to another machine. The attacker then uses a password-cracking program to find additional accounts to exploit. To find out if there are any IDs on your machine that have no password requirement, do the following: 1. From the shell command line, enter: grep :: /etc/passwd This will show you all user IDs that have a pair of colons, or a missing field, in the password file. If the colons appear immediately after the name of the account, as in : guest::1234:10:guest account:/usr/people/guest:/bin/csh Then the account has no password. 2. To close this hole, use jot or another editor to edit /etc/passwd. Change the "::" to ":*:", which locks the password. This will prevent a user from directly logging into the account. 3. To further protect the account, you should also change the shell field (the last field) from the usual value of "/bin/csh" to "/bin/false". This will prevent anyone from remotely logging into the account (using rlogin). The final entry would read: guest:*:1234:10:guest account:/usr/people/guest:/bin/false 4. If the /etc/passwd file is publicly readable on your system, and you did have accounts with no password, you should assume that your password file has been compromised. Once the accounts have been secured, you should then change all the passwords on the live user accounts. Attachment A provides guidance on picking strong passwords. You can change the passwords in two ways: a) Login to the system as root and issue the command passwd Give the new passwords to the users and insist that they change them, using the password guidelines in Attachment A. b) Contact your users by telephone and insist that they log on and change their passwords. You can tell if they have done so by keeping a copy or printout of the password file in its original state and comparing the second field (the encrypted password field) with the new one. If they do not change them in a day or two, lock the passwords and make them come to you to get access. Do not simply expire the users' passwords. If an intruder has access to your system, he or she could change the password and continue using your system. UNRESTRICTED TFTP 1. Another problem that has been seen in SGI machines is unrestricted tftp. tftp (trivial file transfer) is a program that is used to boot diskless workstations. It provides NO user authentication. On the SGI machines, it can be restricted to a directory containing the boot programs. If it is not restricted, any network user can tftp to the host machine and copy any publicly-readable file, such as /etc/passwd. The configuration for tftp may be found in the file /usr/etc/inetd.conf. When running in "secure" (restricted) mode it will look like this: tftp dgram udp wait guest /usr/etc/tftpd tftpd -s where is something like /usr/local/boot. In unrestricted mode the -s parameter will be missing. One method of installing a CD ROM drive on an SGI for network access seems to encourage the installer to remove the restrictions. Do not be misled - if you remove the restrictions, any publicly- readable file will be open to the network. 2. Use the following command to search for programs that execute with the owner's privileges: find / -perm -004000 -o -perm -002000 \) -type f -print Be especially suspicious of any that belong to root and are located in user directories. CHECKING SYSTEM FOR POSSIBLE BREAKINS 1. To search for evidence that your system has been attacked, try the following: a. grep login /usr/adm/SYSLOG >> logins.lst This command will make a list of all the successful and unsuccessful logins on your system since the SYSLOG file was enabled. The list will be stored in the file logins.lst. b. Scan logins.lst looking for any of the IDs that had null passwords. In particular, try the IDs listed in the first paragraph. Also look for logins from outside the local community, for example a university with which you do not normally have communications. Report any suspicious evidence to your Center Computer Security Manager. Be sure to keep both /usr/adm/SYSLOG and logins.lst. 2. You can also scan /usr/adm/sulog to see which users have become superuser with the su command. 3. The IRIX system has options that allow you to configure logging. These are found in the file /etc/config/login.options. Some examples: syslog = all records all login attempts, whether successful or not syslog = fail records only login failures passwdreq requires each user to have a password lastlog when the user logs in, displays the last previous login time ADDITIONAL LOGIN.OPTIONS vulnerability Login.options is a file that contains some parameters for the system's login process. By default, this file is world readable. NASIRC recommends that you change the permissions to read only for root and group by executing the following command as root: chmod /etc/config/login.options 640 Note: the options "syslog=all" or "syslog=fail", set within login.options will not log any login attempts made through the SGI-supplied graphical login process Pandora. In addition, the file where login attempts are kept, /usr/adm/SYSLOG, should also not be world readable. YELLOW PAGES - ALTERNATE PASSWORD FILE If you are using yellow pages (NIS) you can set up an alternate password file with any name and place it anywhere. This password file can be set up to contain only accounts of users that log in remotely (no administrative accounts). Use of this file will make the information in /etc/passwd useless to anyone who might break into your system and try to crack passwords. To define the password file, open or create the file /etc/config/ypmaster.options, and create a line with the text: PWFILE=/path/newpasswdfile.name NOTE: the permissions to /etc/config/ypmaster.options should not allow world read of this file which contains the name and location of the alternate password file. Also note that this feature is available because shadow password files are incompatible with YP. XHOST DEFAULT CONFIGURATION The system default configuration for xhost is "xhost +". This means that any host on the same network can use X protocols to access this machine. X has well known vulnerabilities and there are automated programs that can remotely gain unauthorized access using X. NASIRC recommends that you either deny all access to all hosts through X or authorize only known, trustworthy specific machines. To deny all X access to your system, use the command "xhost -". To restrict X access to selected hosts follow these three steps: a. create or edit the file "/etc/Xn.hosts" where 'n' is the display number of the server on the local host, normally 0, as in "/etc/x0.hosts". To grant access to hosts "newhost.gov" and "secondhost.gov" and no other hosts the file /etc/x0hosts will consist of: +newhost.gov +secondhost.gov b. Search through all files in the directory /usr/lib/X11/xdm for occurances of the command "xhost +" or "/usr/bin/X11/xhost+". Remove or comment out all such lines. For SGI IRIS these files are by default: /usr/lib/X11/xdm/xsession /usr/lib/X11/xdm/xsession-remote /usr/lib/X11/xdm/xsession.0 c. Inform users that any xhost commands should be removed or commented out of user startup scripts, such as .cshrc, .login, .profile, etc. To add an additional level of security to your X environment, NASIRC recommends the use of xauthority for host access control. To set up xauthority, edit the file /usr/lib/X11/xdm/xdm-config by replacing the "off" with "on" in the following line: DisplayManager*authorize:off After all changes are made, SGI recommends that you reboot your machine to ensure that all changes take effect, and change all passwords for all users' accounts that may have been compromised. To ensure that X has been turned off for non-registered hosts, perform the following test commands from an invalid machine: setenv DISPLAY yourhostname:0 /usr/bin/X11/xterm If a message appears which refuses the connection, then you have configured your system correctly. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Security checklists, toolkits and guidance are available from the NASIRC online archives. Contact the NASIRC Helpdesk for more information and assistance with toolkits or security measures. NASIRC ACKNOWLEDGES: Lee Snapp (Johnson Space Center), Emily Lonsford (Mitre Corporation/JSC), John Ray and Dave Gehrt (Ames Research Center), and the DoE CIAC Team for for their investigations, analysis and coordination of the information contained in this bulletin. ================================================================== For further assistance, please contact the NASIRC Helpdesk: Phone: 1-800-7-NASIRC Fax: 1-301-306-1010 Internet Email: nasirc@nasa.gov 24 Hour/Emergency Pager: 1-800-759-7243/Pin:5460866 ================================================================== This bulletin may be forwarded without restrictions to sites and system administrators within the NASA community ----------------- PLEASE NOTE: Users outside of the NASA community may receive NASIRC bulletins. If you are not part of the NASA community, please contact your agency's response team to report incidents. Your agency's team will coordinate with NASIRC, who will ensure the proper internal NASA team(s) are notified. NASIRC is a member of the Forum of Incident Response and Security Teams (FIRST), a world-wide organization which provides for coordination between incident response teams in handling computer-security-related issues. A list of FIRST member organizations and their constituencies can be obtained by sending email to docserver@first.org with an empty subject line and a message body containing the line: send first-contacts.