From thegnome@NMRC.ORG Wed Sep 23 13:15:24 1998 From: Simple Nomad 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. _______________________________________________________________________________