home *** CD-ROM | disk | FTP | other *** search
/ Forum of Incident Response & Security Teams / Forum_of_Incident_Response_and_Security_Teams_FIRST_October_1994.iso / teaminfo / nasirc / nasa9305.txt < prev    next >
Text File  |  1994-07-02  |  13KB  |  280 lines
  1.  
  2.      NASIRC BULLETIN #93-05                          October 22, 1993
  3.  
  4.                     SGI/IRIX CONFIGURATION VULNERABILITIES
  5.   ===========================================================================
  6.                __    __      __      ___   ___  ____     ____  
  7.               /_/\  /_/|    /_/     / _/\ /_/| / __/ \  / __/\ 
  8.               | |\ \| ||   /  \ \   | /\/ | || | /\ \/  | | \/ 
  9.               | ||\ \ ||  / /\ \ \   \ \  | || |_\/ /\  | |    
  10.               | || \ \|| / /--\ \ \ /\_\\ | || | |\ \ \ | \_/\ 
  11.               |_|/  \_|//_/    \_\/ \/__/ |_|/ |_| \_\/ \___\/ 
  12.              NASA Automated Systems Incident Response Capability
  13.   ===========================================================================
  14.  
  15.    NASIRC has received information indicating that SGI IRIX systems
  16.    configured with operating system defaults are vulnerable to attack. The
  17.    auto-installation procedure leaves some default accounts vulnerable to
  18.    compromise, some files are left world readable, and the default
  19.    configuration for xhost is vulnerable.  This bulletin reminds IRIX system
  20.    administrators to check various default settings on their systems. 
  21.  
  22.  
  23. OPEN ACCOUNTS
  24.  
  25.    Silicon Graphics IRIX machines come with several well-known
  26.    vendor-supplied user IDs that have no password.  This means that anyone
  27.    who guesses that your machine is an IRIX machine can attempt to login
  28.    using one of these IDs. (Generally, using telnet to a machine will cause
  29.    it to display its operating system type and version number.)  The IDs that
  30.    have been seen in the local area are: 
  31.  
  32.         tutor        guest
  33.         demos        lp
  34.         uucp         nuucp
  35.         4Dgifts      diag (may have superuser privileges)
  36.  
  37.    Because of the powerful graphical user interface, IRIX users may be
  38.    unaware of the vulnerable IDs, or how to protect them.  Given any access
  39.    to the system, attackers can usually find additional exposures that will
  40.    allow them to gain superuser access.  In some cases, a non-privileged
  41.    account such as guest has been used to copy any publicly readable file,
  42.    such as the password file, /etc/passwd, to another machine.  The attacker
  43.    then uses a password-cracking program to find additional accounts to
  44.    exploit. 
  45.  
  46.    To find out if there are any IDs on your machine that have no password
  47.    requirement, do the following: 
  48.  
  49.    1.    From the shell command line, enter:  grep :: /etc/passwd
  50.  
  51.    This will show you all user IDs that have a pair of colons, or a
  52.    missing field, in the password file.  If the colons appear immediately
  53.    after the name of the account, as in : 
  54.    
  55.         guest::1234:10:guest account:/usr/people/guest:/bin/csh
  56.  
  57.    Then the account has no password.
  58.  
  59.    2.    To close this hole, use jot or another editor to edit /etc/passwd.
  60.    Change the "::" to ":*:", which locks the password.  This will prevent a
  61.    user from directly logging into the account. 
  62.  
  63.    3.    To further protect the account, you should also change the shell
  64.    field (the last field) from the usual value of "/bin/csh" to "/bin/false".
  65.    This will prevent anyone from remotely logging into the account (using
  66.    rlogin). The final entry would read: 
  67.  
  68.         guest:*:1234:10:guest account:/usr/people/guest:/bin/false
  69.  
  70.    4.    If the /etc/passwd file is publicly readable on your system, and you
  71.    did have accounts with no password, you should assume that your password
  72.    file has been compromised.  Once the accounts have been secured, you
  73.    should then change all the passwords on the live user accounts. 
  74.    Attachment A provides guidance on picking strong passwords.  You can
  75.    change the passwords in two ways: 
  76.  
  77.     a)    Login to the system as root and issue the command
  78.  
  79.             passwd <username>
  80.    
  81.    Give the new passwords to the users and insist that they change them,
  82.    using the password guidelines in Attachment A. 
  83.  
  84.    b)    Contact your users by telephone and insist that they log on and
  85.    change their passwords.  You can tell if they have done so by keeping a
  86.    copy or printout of the password file in its original state and comparing
  87.    the second field (the encrypted password field) with the new one.  If they
  88.    do not change them in a day or two, lock the passwords and make them come
  89.    to you to get access. 
  90.    
  91.    Do not simply expire the users' passwords.  If an intruder has access to
  92.    your system, he or she could change the password and continue using your
  93.    system. 
  94.  
  95.  
  96. UNRESTRICTED TFTP 
  97.  
  98.    1.    Another problem that has been seen in SGI machines is unrestricted
  99.    tftp. tftp (trivial file transfer) is a program that is used to boot
  100.    diskless workstations.  It provides NO user authentication.  On the SGI
  101.    machines, it can be restricted to a directory containing the boot
  102.    programs.  If it is not restricted, any network user can tftp to the host
  103.    machine and copy any publicly-readable file, such as /etc/passwd. 
  104.  
  105.    The configuration for tftp may be found in the file
  106.    /usr/etc/inetd.conf. When running in "secure" (restricted) mode it will
  107.    look like this: 
  108.  
  109.      tftp  dgram  udp   wait  guest  /usr/etc/tftpd  tftpd -s <directory>
  110.  
  111.    where <directory> is something like /usr/local/boot. In unrestricted mode
  112.    the -s parameter will be missing.  One method of installing a CD ROM drive
  113.    on an SGI for network access seems to encourage the installer to remove
  114.    the restrictions.  Do not be misled - if you remove the restrictions, any
  115.    publicly- readable file will be open to the network. 
  116.  
  117.    2.    Use the following command to search for programs that execute with
  118.    the owner's privileges: 
  119.  
  120.         find / -perm -004000 -o -perm -002000 \) -type f -print
  121.  
  122.    Be especially suspicious of any that belong to root and are located in
  123.    user directories. 
  124.  
  125.  
  126. CHECKING SYSTEM FOR POSSIBLE BREAKINS 
  127.  
  128.    1.    To search for evidence that your system has been attacked, try the
  129.    following: 
  130.  
  131.    a.    grep login /usr/adm/SYSLOG >> logins.lst
  132.  
  133.    This command will make a list of all the successful and unsuccessful
  134.    logins on your system since the SYSLOG file was enabled.  The list will be
  135.    stored in the file logins.lst. 
  136.  
  137.    b.    Scan logins.lst looking for any of the IDs that had null passwords. 
  138.    In particular, try the IDs listed in the first paragraph.  Also look for
  139.    logins from outside the local community, for example a university with
  140.    which you do not normally have communications.  Report any suspicious
  141.    evidence to your Center Computer Security Manager.  Be sure to keep both
  142.    /usr/adm/SYSLOG and logins.lst. 
  143.    
  144.    2.    You can also scan /usr/adm/sulog to see which users have become
  145.    superuser with the su command. 
  146.    
  147.    3.    The IRIX system has options that allow you to configure logging. 
  148.    These are found in the file /etc/config/login.options.  Some examples: 
  149.  
  150.      syslog = all   records all login attempts, whether successful or not
  151.          syslog = fail  records only login failures
  152.          passwdreq      requires each user to have a password
  153.          lastlog        when the user logs in, displays the last previous
  154.                         login time
  155.  
  156.  
  157. ADDITIONAL LOGIN.OPTIONS vulnerability
  158.  
  159.    Login.options is a file that contains some parameters for the system's
  160.    login process.  By default, this file is world readable.  NASIRC
  161.    recommends that you change the permissions to read only for root and group
  162.    by executing the following command as root: 
  163.  
  164.        chmod /etc/config/login.options 640
  165.  
  166.    Note: the options "syslog=all" or "syslog=fail", set within login.options
  167.    will not log any login attempts made through the SGI-supplied graphical
  168.    login process Pandora.  In addition, the file where login attempts are
  169.    kept, /usr/adm/SYSLOG, should also not be world readable. 
  170.  
  171. YELLOW PAGES - ALTERNATE PASSWORD FILE
  172.  
  173.    If you are using yellow pages (NIS) you can set up an alternate password
  174.    file with any name and place it anywhere.  This password file can be set
  175.    up to contain only accounts of users that log in remotely (no
  176.    administrative accounts).  Use of this file will make the information in
  177.    /etc/passwd useless to anyone who might break into your system and try to
  178.    crack passwords. 
  179.    
  180.    To define the password file, open or create the file
  181.    /etc/config/ypmaster.options, and create a line with the text: 
  182.  
  183.        PWFILE=/path/newpasswdfile.name 
  184.    
  185.    NOTE: the permissions to /etc/config/ypmaster.options should not allow
  186.    world read of this file which contains the name and location of the
  187.    alternate password file.  Also note that this feature is available because
  188.    shadow password files are incompatible with YP. 
  189.  
  190.  
  191. XHOST DEFAULT CONFIGURATION
  192.  
  193.    The system default configuration for xhost is "xhost +".  This means that
  194.    any host on the same network can use X protocols to access this machine. 
  195.    X has well known vulnerabilities and there are automated programs that can
  196.    remotely gain unauthorized access using X.  NASIRC recommends that you
  197.    either deny all access to all hosts through X or authorize only known,
  198.    trustworthy specific machines. 
  199.    
  200.    To deny all X access to your system, use the command "xhost -". 
  201.    
  202.    To restrict X access to selected hosts follow these three steps: 
  203.    
  204.    a. create or edit the file "/etc/Xn.hosts" where 'n' is the display   
  205.    number of the server on the local host, normally 0, as in   
  206.    "/etc/x0.hosts". 
  207.    
  208.    To grant access to hosts "newhost.gov" and "secondhost.gov" and no   
  209.    other hosts the file /etc/x0hosts will consist of: 
  210.  
  211.           +newhost.gov    +secondhost.gov 
  212.  
  213.    b. Search through all files in the directory /usr/lib/X11/xdm for   
  214.    occurances of the command "xhost +" or "/usr/bin/X11/xhost+".  Remove or
  215.    comment out all such lines.  For SGI IRIS these files are by default: 
  216.  
  217.        /usr/lib/X11/xdm/xsession
  218.        /usr/lib/X11/xdm/xsession-remote
  219.        /usr/lib/X11/xdm/xsession.0
  220.  
  221.    c. Inform users that any xhost commands should be removed or commented   
  222.    out of user startup scripts, such as .cshrc, .login, .profile, etc. 
  223.    
  224.    To add an additional level of security to your X environment, NASIRC
  225.    recommends the use of xauthority for host access control.  To set up
  226.    xauthority, edit the file /usr/lib/X11/xdm/xdm-config by replacing the
  227.    "off" with "on" in the following line: 
  228.  
  229.        DisplayManager*authorize:off
  230.  
  231.    After all changes are made, SGI recommends that you reboot your machine to
  232.    ensure that all changes take effect, and change all passwords for all
  233.    users' accounts that may have been compromised. 
  234.  
  235.    To ensure that X has been turned off for non-registered hosts, perform the
  236.    following test commands from an invalid machine: 
  237.    
  238.        setenv DISPLAY yourhostname:0
  239.        /usr/bin/X11/xterm
  240.    
  241.    If a message appears which refuses the connection, then you have
  242.    configured your system correctly. 
  243.  
  244. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  245.  
  246.    Security checklists, toolkits and guidance are available from the
  247.    NASIRC online archives. Contact the NASIRC Helpdesk for more
  248.    information and assistance with toolkits or security measures.
  249.  
  250.  NASIRC ACKNOWLEDGES: Lee Snapp (Johnson Space Center), Emily Lonsford
  251.     (Mitre Corporation/JSC), John Ray and Dave Gehrt (Ames Research Center), 
  252.     and the DoE CIAC Team for for their investigations, analysis and
  253.     coordination of the information contained in this bulletin. 
  254.  
  255.       ==================================================================
  256.         For further assistance, please contact the NASIRC Helpdesk:
  257.     Phone: 1-800-7-NASIRC                Fax: 1-301-306-1010
  258.     Internet Email: nasirc@nasa.gov
  259.         24 Hour/Emergency Pager: 1-800-759-7243/Pin:5460866
  260.       ==================================================================
  261.       This bulletin may be forwarded without restrictions to sites and 
  262.       system administrators within the NASA community
  263.  
  264.                             -----------------
  265.  
  266.  PLEASE NOTE: Users outside of the NASA community may receive NASIRC
  267.     bulletins.  If you are not part of the NASA community, please contact
  268.     your agency's response team to report incidents.  Your agency's team
  269.     will coordinate with NASIRC, who will ensure the proper internal 
  270.     NASA team(s) are notified. NASIRC is a member of the Forum of Incident
  271.     Response and Security Teams (FIRST), a world-wide organization which 
  272.     provides for coordination between incident response teams in handling 
  273.     computer-security-related issues. 
  274.  
  275.     A list of FIRST member organizations and their constituencies can be
  276.     obtained by sending email to docserver@first.org with an empty subject
  277.     line and a message body containing the line: send first-contacts. 
  278.  
  279.  
  280.