From thegnome@NMRC.ORG Wed Sep 23 13:15:24 1998
From: Simple Nomad <thegnome@NMRC.ORG>
To: BUGTRAQ@netspace.org
Date: Fri, 18 Sep 1998 04:18:39 -0500
Subject: NMRC Advisory - Default NDS Rights

_______________________________________________________________________________

                          Nomad Mobile Research Centre
                                 A D V I S O R Y
                                  www.nmrc.org
                        Simple Nomad [thegnome@nmrc.org]
                                   16Sep1998
_______________________________________________________________________________

                              Platform : Novell NetWare
                           Application : NDS
                              Severity : Medium


Synopsis
--------

Default settings during NDS installation reveal account names and other
information to users who have not logged in. Learning potential account
names is usually the first step before an intruder attacks a computer
system.

Tested configuration
--------------------

The default settings were tested with the following configuration :

Novell NetWare 4.1, 4.11
Service Pack 5
NDS 5.99
Various Clients

It has also been confirmed by others outside of NMRC on virtually all
NetWare systems > 3.x.

Bug(s) report
-------------

CX.EXE and NLIST.EXE both exist by default in the SYS:LOGIN directory.
Upon loading the client software, the client connects to the preferred
server with a NOT-LOGGED-IN connection. The unauthenticated client has
access to CX.EXE and NLIST.EXE. This access in itself is not the problem,
the problem lies in the default Read access at the root of the tree. These
rights are "inherited" down the tree unless specifically blocked, allowing
read access to most NDS objects in the tree. Most objects in the tree have
at least Read access to the object type and name by default.

The following commands can be issued by a client connected to a NetWare
4.x or IntranetWare server, revealing most if not all user account names,
in addition to most if not the entire tree layout.

CX /T /A /R         - list all readable user and container object names in
                      tree, and can give a rather accurate layout of the
                      containers and basic contents
NLIST USER /D       - list info regarding user names in current context
NLIST GROUPS /D     - list groups and group membership in current context
NLIST SERVER /D     - list server names and OS versions, and if attached
                      reveal if accounting is installed or not
NLIST /OT=* /DYN /D - list all readable objects, including dynamic
                      objects, names of NDS trees, etc

Through a combination attaching to different servers and switching
contexts, a potential intruder could determine the general layout
regarding NDS, potentially even which servers contain certain replicas of
the NDS database.

The main information revealed is a list of potential user accounts for
an intruder to use to gain access to a NetWare server. Once in, even
limited accounts can re-run the above commands revealing even more
information than before. The scenario is further damaging due to the
fact that Intruder Detection is off by default.

Solution/Workaround
-------------------

Disable public Read access from the root of your NDS tree. Ensure all
accounts have passwords, and that all assigned passwords are not easily
guessed. Ensure Intruder Detection is turned on at the root of your NDS
tree.

Comments
--------

This is certainly not a new problem. The revealing nature of CX has been
discussed on USENET and has been reported in the NetWare Hack FAQ. The
problem is that installations of NDS left rather unsecure seems to go on
repeatedly despite the earlier warnings.

NMRC is unaware of any tools or processes that might "undo" a workaround
(outside of a tape restore), but it advised that after using any NDS
global utility such as DSREPAIR or DSMAINT the rights should be rechecked
to ensure all security safeguards are in place. It was reported several
months ago to NMRC that this could happen, although we were unable to
reproduce the results. YMMV.

Novell is aware of this issue as the CX problems were made public more
than a year ago, however both CX and NLIST are working as designed. This
doesn't excuse Novell from responsibility - adequate documentation should
be provided outlining the danger of not properly configuring NDS rights.
While some environments might require a fairly open NDS tree,
administrators should be given more secure options during initial server
setup, or perhaps some design issues involving users not yet authenticated
to the server need to be revisted.

_______________________________________________________________________________