No idea if this is what the Groupwise Padlock (http://www.novell.com/padlock) thing is about, since Novell is not only vague in the issues, but never acknowledged Adept's findings. - Simple Nomad - "No rest for the Wicca'd" - - thegnomeat_private - - - thegnomeat_private - www.nmrc.org razor.bindview.com - ----- _______________________________________________________________________________ Nomad Mobile Research Centre A D V I S O R Y www.nmrc.org Adept [adeptat_private] Simple Nomad [thegnomeat_private] 14Aug2001 _______________________________________________________________________________ Platform : Novell NetWare 5.x Application : NetWare Enterprise Web Server 5.1 GroupWise WebAccess 5.5 Severity : Various Synopsis -------- The NetWare Enterprise Web Server 5.1 has a couple of security problems, and these problems are related to additional products being used, such as GroupWise WebAccess. Tested configuration -------------------- Testing was done with the following configuration : Novell Netware 5.x, latest Service Pack GroupWise WebAccess, latest versions Issue #1 - Information Leak --------------------------- When NDS browsing via the web server is enabled, if an attacker can reach that server's port 80 they can enumerate information such as user names, group names, and other system information. The default location for gaining this information is http://server/lcgi/ndsobj.nlm, which if NDS browsing is enabled will allow the enumeration. This is not especially a GroupWise problem, but WebAccess can "intensify" the leakage, as it allows for more objects to browse. This is simply a new flavor on an old problem (see http://www.nmrc.org/advise/nds1.txt and http://razor.bindview.com/publish/advisories/adv_novellleak.html for additional information). Mitigation for Issue #1 ----------------------- The NDS browser is disabled by default, which is good. If enabled, you can disable it by performing the following steps from the WEBMGR utility: 1. Click File. 2. Click Select Server and select the appropriate server. 3. Select the \WEB directory on the drive that is mapped to the server and click OK. 4. Uncheck the Enable NDS browsing check box and click OK. 5. Click Save and Restart. 6. Enter the Web Server password and click OK. Alternately you can remove [Public] read access from the root of the NDS tree(s), which will keep everyone, including internal non-authenticated users from browsing your internal tree. Solution/Workaround for Issue #1 -------------------------------- Awaiting an official response from Novell, including acknowledgement of the problem. They were notified a few months ago. Issue #2 - Directory Listing ---------------------------- Poor handling of GET commands will allow for GroupWise WebAccess servers to display indexes of the directories instead of HTML files. We have been unable to get this to work consistently. Basically, instead of issuing a "GET / HTTP/1.1" from NetCat against port 80 on the target system, using "get / http/1.1" causes a directory listing to be displayed if indexing of directories is allowed, instead of a 501 or 502 error when indexing of directories is disallowed. Mitigation for Issue #2 ----------------------- Unknown, possibly disabling indexing of directories on the web server. Solution/Workaround for Issue #2 -------------------------------- Awaiting an official response from Novell, including acknowledgement of the problem. They were notified a few months ago. Comments -------- Adept discovered these items, in certain cases it is possible to remotely read email via port 80. This isn't exactly "point and click" to do, but you get the idea. Adept came to NMRC for verification and assistance with the advisory since his efforts (using Novell's reporting mechanisms, and even using the bug itself to locate internal personnel within Novell that might help) were futile. Apparently no one is reading email at secureat_private, and since they are not, we will probably be releasing additional advisories according to the NMRC disclosure policy, which while not as verbous as RFPolicy is fairly close to the same thing (http://www.nmrc.org/advise/policy.txt). There are other problems that exist, and if Novell is going to drag their feet and not use the notification method that NMRC helped get established there, well, tough darts. Greetz ------ It has been said that using Greetz in source code and advisories is lame and childish. However, we being mature professionals disagree. So big shout-outs to our brothas at eEye (you are right in full disclosure, don't listen to the naysayers), our homies at Attrition (you are not just a mirror of defacements, some of us know and appreciate that), RFP, Zope Kitten, Lew NotTheAsshole, Blu Pi-thon, Neural Cowboy, cDc, rubberhose.org (great idea), witness.org (give 'til it hurts), and everyone else we forgot. And Adept sends a special shout-out to hektik.org. _______________________________________________________________________________
This archive was generated by hypermail 2b30 : Wed Aug 15 2001 - 13:50:38 PDT