First of all, simply displaying login ID's or their context is not necessarily a security risk (millions disagree, I know, but it's not the real risk), provided all other aspects of the security system are in tact. What IS a risk is faulty passwords (ie blank, easily guessed, never expire, etc). In this case, the real risk is the carelessness of the administrator, not a flaw with the system. What you're suggesting here is not really a fix, rather it is a removal of necessary functionality needed by "trusted" users of a Novell network. In fact, Novell has said that it is widely known that, if the presence if CX or NLIST poses some paranoia in your environment, you should delete these utilities from SYS:LOGIN, not modify the rights structure of the NDS tree. (I happened to learn this in training but others will more than likely concur). A non-logged in connection NEEDS read access to containers in order to set their starting context as well as walk the tree if the default context is not correct. By virtue of READ being on the container, all objects in that container can be displayed. It's a judgement call whether or not this poses any *real* threat. Besides, just to get access to the SYS:LOGIN directory itself is quite a touch trick. Unless *all* routers along a given path are running IPX or the site is running Netware IP, it would take some pretty nifty talent to even get to the LOGIN directory. Of course, you can never prevent the internal threat. -- dcc -- -------------- [NDS for NT Project Manager at Novell]: "We've got some good new and some bad news for you: The good news is, we don't mess with NT security. The bad new is....We don't mess with NT security..." > -----Original Message----- > From: Simple Nomad [SMTP:thegnomeat_private] > Sent: Friday, September 18, 1998 5:19 AM > To: BUGTRAQat_private > Subject: NMRC Advisory - Default NDS Rights > > __________________________________________________________________________ > _____ > > Nomad Mobile Research Centre > A D V I S O R Y > www.nmrc.org > Simple Nomad [thegnomeat_private] > 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. > > __________________________________________________________________________ > _____
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:16:59 PDT