[60] in Intrusion Detection Systems
CIAC BULLETIN F-19 (1/2)
daemon@ATHENA.MIT.EDU (Frank Swift (510-422-1463))
Wed Apr 5 19:54:50 1995
Date: Wed, 5 Apr 1995 10:15:49 -0700
To: ids@uow.edu.au
From: uncl@llnl.gov (Frank Swift (510-422-1463))
Reply-To: ids@uow.edu.au
Date: Wed, 5 Apr 1995 09:19:24 -0700
Errors-To: listmanager@cheetah.llnl.gov
Reply-To: ssparks@llnl.gov
Originator: ciac-bulletin@cheetah.llnl.gov
Sender: ciac-bulletin@cheetah.llnl.gov
Precedence: bulk
From: ssparks@llnl.gov (Sandy Sparks)
To: uncl@llnl.gov
Subject: CIAC BULLETIN F-19
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
_____________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
_____________________________________________________
INFORMATION BULLETIN
Protecting HP-UX Systems Against SATAN
April 4, 1995 1600 PST Number F-19
______________________________________________________________________
PROBLEM: SATAN, a tool for scanning Unix systems is scheduled to
be released on April 5. The tools identifies exploitable
vulnerabilities; most of which can be patched.
PLATFORM: This bulletins focuses on SATAN's impact on HP-UX
Systems.
DAMAGE: Anyone running SATAN can gain vulnerability information
that can be exploited with other tools to gain privileged
access.
SOLUTION: Update all HP-UX systems with the patches identified
below.
AVAILABILITY: All patches are available now.
______________________________________________________________________
VULNERABILITY When SATAN is released via the Internet on April 5,
ASSESSMENT: it will be available to anyone, including system
administrators and security specialists who protect
corporate systems. It will also be 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 HP-UX Vulnerabilities
CIAC has obtained information from Hewlett Packard describing the
specific patches for the vulnerabilities SATAN will scan for. Specific
patch details are provided below.
[Begin HP Bulletin]
------------------------------------------------------------------------
HEWLETT-PACKARD SECURITY BULLETIN: #00026, 3 April 1995
******** ADVISORY ONLY ********
------------------------------------------------------------------------
Hewlett-Packard recommends that the information in the following
Security Bulletin should be acted upon as soon as possible. Hewlett-
Packard will not be liable for any consequences to any customer
resulting from customer's failure to fully implement instructions in
this Security Bulletin as soon as possible.
______________________________________________________________________
ISSUE: Release of SATAN program strengthens need for vigilant system
administration.
PLATFORM: All HP-UX systems
ACTIONS: Install portmap patches specified below, and consider advice
discussed below.
PATCHES:
--------
ISSUE #1: Portmap permits forwarding of requests.
DAMAGE : Remote users can gain unauthorized access to exported file
systems.
SOLUTION: Apply patch PHNE_4879 (series 700/800, HP-UX 9.x), or
PHNE_5081 (series 300/400, HP-UX 9.0), or
PHNE_5156 (series 300/400, HP-UX 8.x)
For 700/800, HP-UX 8.x, disable portmap.
ISSUE #2:
ENHANCEMENT FOR HP-UX 9.x:
Strengthen NIS authentication.
NIS client/server enhancement for access control lists:
Apply patch PHNE_4958 (series 700/800,HP-UX 9.x), or
PHNE_5081 (series 300/400, HP-UX 9.x)
ISSUE #3: NTP should not be used as the time source for HP-DCE/9000
until further notice.
PLATFORM: All HP-UX systems
DAMAGE: HP-DCE/9000 could require reconfiguration and re-installation.
ACTIONS: Implement procedure discussed below before running SATAN.
______________________________________________________________________
.......................................................................
Preparing Your HP-UX System for SATAN
Bob Kelley
bkelley@cup.hp.com
HP-UX Security Response Team
I. SATAN vs. HP-UX
A. Writable FTP Home Directory
B. Unprivileged NFS Access
C. Unrestricted NFS Export
D. NIS Password File Access
E. Portmap Forwarding
F. TFTP File Access
G. Remote Shell Access
H. Vulnerability in rexd configuration
I. Sendmail Vulnerabilities
J. X Server Access
K. NTP vulnerabilities and HP-DCE/9000
II. Additional Advice on Network Security
A. Fingerd
B. Inetd and /usr/adm/inetd.sec
C. Passwords
D. Message Off
E. Denial of Service Attacks
F. IP Spoofing
G. RIP Updates
H. Controlling Root Access
I. DNS Searchlist / RFC 1535
J. Vulnerability in rusersd configuration
III. HP-UX Patch Information
IV. HP SupportLine and HP Security Bulletins
V. Report vulnerabilities to security-alert@hp.com
.......................................................................
I. SATAN vs. HP-UX
The Hewlett-Packard HP-UX Security Response Team has tested beta version
0.50 of the Security Analysis Tool for Analyzing Networks (SATAN). This
advisory contains information based on our review of this pre-release
version. SATAN is scheduled for release on April 5, 1995 at 14:00 GMT.
SATAN is a World Wide Web based tool that automates network
vulnerability testing and reporting. Documentation on SATAN can be found
at:
ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z
SATAN gathers information about hosts or networks by remotely examining
network services. It then generates a summary of the potential
vulnerabilities discovered on those hosts. In addition, it offers a
brief description of the vulnerabilities, and possible workarounds to
those vulnerabilities. At this time, SATAN does not actively use these
vulnerabilities to break into the examined hosts.
SATAN's construction provides a flexible framework for examining network
vulnerabilities and reporting test results. Each time SATAN is run,
tests can be aimed at a single host, hosts on a network, or hosts
connected to the target host. The testing can expand exponentially to
multiple "levels" away from the target system or target network, adding
many hosts to the list of examined systems.
SATAN is quite extensible: perl scripts designed to examine new network
vulnerabilities can easily be added. Combining this extensibility with
the automation of quickly examining many hosts allows SATAN to quickly
discover vulnerable hosts.
The initial distribution of SATAN looks for about ten vulnerabilities.
As a result of publicity, it is likely that additional tests will be
added to SATAN. The first part of this advisory deals with the
initial ten vulnerabilities that SATAN targets:
A. Writable FTP Home Directory
The ftpd man page provides appropriate recommendations for the
permissions and ownership of all the sub-directories, but erroneously
recommends that the ~ftp home directory be owned by ftp. This allows an
anonymous ftp user to change the permission on the ~ftp home directory,
and control (read/modify/delete) any files owned by ftp in the ~ftp home
directory.
Make sure that the login shell of the ftp account is de-activated by
putting a '*' in the password field of the /etc/passwd line, and
referencing /bin/false as the login shell.
Do not place a complete copy of /etc/passwd into ~ftp/etc to prevent
distribution of the passwd file to hackers for cracking. Instead, put
'*' into the password part of each account in the ~ftp/etc/passwd file.
Also, try to remove any accounts from the ~ftp/etc/passwd file of users
that will not be using ftp.
B. Unprivileged NFS Access
1. The problem
rpc.mountd is usually started from /etc/netnfsrc by setting
START_MOUNTD=1. Starting rpc.mountd in this manner provides little
confidence in the originator of the mount RPC request. An intruder could
gain access to the exported file system. If you are concerned about the
security of exported file systems, starting rpc.mountd from
/etc/netnfsrc may be a vulnerability.
2. Fixing the problem
This vulnerability can be closed by only starting rpc.mountd from
/etc/inetd.conf and using /usr/adm/inetd.sec to control which clients
may have access to the rpc.mountd program.
Uncomment (or add) the rpc.mountd line in /etc/inetd.conf:
rpc dgram udp wait root /usr/etc/rpc.mountd 100005 1 rpc.mountd -e
The "-e" option causes rpc.mountd to exit after serving each RPC
request, allowing inetd.sec to validate the authority of each RPC
request.
Be sure to start inetd with logging turned on (inetd -l) by modifying
the /etc/netlinkrc line for inetd from:
[ -x /etc/inetd ] && /etc/inetd && /bin/echo "inetd \c"
to be:
[ -x /etc/inetd ] && /etc/inetd -l && /bin/echo "inetd \c"
3. Limitations
rpc.mountd handles each RPC request properly using inetd, as NFS is a
stateless protocol that relies on RPC and UDP packets to deal with mount
requests. However, showmount (1M) cannot be used when rpc.mountd is
started from inetd since showmount uses TCP to get information from
rpc.mountd and inetd only registers the udp port.
C. Unrestricted NFS Export
Make sure all file exports specify an explicit list of clients or
netgroups. Empty host fields in netgroups are treated as wildcards,
allowing any host to gain access to the file system, so be very
careful when using these wildcards.
Avoid exporting file systems with write capability if possible. Avoid
exporting file systems for root access if at all possible.
D. NIS Password File Access
Make the NIS domain name a difficult one to guess, to prevent
unauthorized ypbinds from binding to the server. Enforce good password
selection when using NIS to serve passwd maps, as it is quite
likely that a hacker would be able to guess the domain name and get a
copy of the /etc/passwd file to run a password cracker against.
An enhancement to HP-UX 9.x added an access control list to NIS. The
/etc/securenets file is used by both clients and servers. On the NIS
server, this file lists networks and hosts which may access NIS maps
from this server. On the NIS client, this file lists networks and hosts
which may act as NIS servers when ypbind attempts to find a server.
To add the /etc/securenets functionality, install these patches:
9.x s700_800 PHNE_4879
9.x s300_400 PHNE_5081
E. Portmap Forwarding
This problem is fixed in most versions of HP-UX, when these patches are
applied:
9.x s700_800: PHNE_4879
9.x s300_400: PHNE_5081
8.x s300_400: PHNE_5156
Running portmap on a s700 or s800 with 8.x is vulnerable to this attack.
If you are concerned with the security of such a system, disable portmap
or upgrade to 9.x.
F. TFTP File Access
HP's tftpd only allows access to the /usr/tftpdir directory and files in
paths specified in the inetd.conf startup line.
Be careful not to offer access to directories containing vital
information (/, /etc, or others), since tftp offers minimal protection.
(The initial startup of tftpd is controlled by inetd which can control
access via inetd.sec; however, once tftpd is running, no further
validation is done by tftpd on new requests.)
Make sure files in /usr/tftpdir cannot be overwritten by user tftp by
turning write permissions off.
Make sure that the login shell of the tftp account is de-activated by
putting a '*' in the password field of the /etc/passwd line, and
referencing /bin/false as the login shell.
G. Remote Shell Access
Using remsh (rsh), rlogin, or rcp permits a system to grant privileges
without the user typing a password. In a secure environment, behind a
properly configured firewall, these services can be helpful. Each user
can create a .rhosts file to allow easy access to each host.
However, if your hosts are connected to an unsecure network (say, the
Internet), it is dangerous to grant privileges based on a hostname and
an IP address: you should consider disabling these services by removing
them from /etc/inetd.conf, or by commenting them out in /etc/inetd.conf:
#login stream tcp nowait root /etc/rlogind rlogind
#shell stream tcp nowait root /etc/remshd remshd
If you do decide to use them in an UNSECURE environment, consider using
them WITHOUT .rhosts files, and WITHOUT a /etc/hosts.equiv file. As the
super-user, you control the existance and contents of the /.rhosts and
/etc/hosts.equiv files. Furthermore, you can use the "-l" options
to enforce a policy of preventing users from using .rhosts files.
The remote shell daemon (remshd(1M), known as rshd on non-HP-UX
systems), offers a "-l" option to prevent authentication based on the
user's .rhosts file unless the user is the super-user. Rlogind(1M) also
offers a "-l" option. Both of these services are started from inetd, so
you can add the "-l" option to their entries in /etc/inetd.conf:
login stream tcp nowait root /etc/rlogind rlogind -l
shell stream tcp nowait root /etc/remshd remshd -l
In HP-UX, "+::" in the /etc/passwd file indicates a switch to the NIS
map. It will NOT allow a login as user "+", so you should NOT put "+:*:"
in these files. In HP-UX, "+:*:" indicates that the NIS map should be
consulted, but that all NIS accounts should be de-activated!
A '+' in the /etc/hosts.equiv file is a wildcard that indicates that any
remote host will be approved for access. So, do NOT put a '+' in
/etc/hosts.equiv.
A '+ +' in /.rhosts (or any .rhosts) indicates that any remote user is
approved for access. So, do NOT put a '+ +' in the /.rhosts file or in
any .rhosts file.
For maximum security, do not list user names in /etc/hosts.equiv: only
list system names.
Finally, remember to only use .rhosts or hosts.equiv files in a trusted
environment, behind a firewall.
H. Vulnerability in rexd configuration
1. The problemThe default setting for rexd in the /etc/inetd.conf file
is as follows:
#rpc stream tcp nowait root /usr/etc/rpc.rexd 100017 1 rpc.rexd
If you uncomment this line to enable rexd, an intruder can masquerade as
a trusted system and trusted user.
2. Fixing the problems
This vulnerability can easily be closed by adding the -r option to the
rpc.rexd entry in the /etc/inetd.conf file:
rpc stream tcp nowait root /usr/etc/rpc.rexd 100017 1 rpc.rexd -r
Rexd should only be invoked with the "-r" option. This option specifies
that only hosts listed in /etc/hosts.equiv are permitted to use the
rexd.
I. Sendmail Vulnerabilities
HP Security Bulletin #25 provides a list of the latest sendmail patches.
By installing these patches, all known sendmail bugs are fixed. Even
though SATAN tries to infer the status of sendmail by connecting to the
SMTP port and reading the banner, this will not directly provide
information on the patch level.
Consider using site hiding in your /usr/lib/sendmail.cf file (the DY
macro) to hide system names inside your network.
J. X Server Access
Users should not run with "xhost +", as this permits access to the X
server from arbitrary hosts. A better level of protection is provided by
at least specifying hosts which are permitted access by using "xhost
