groupwise.disclosure.txt

2001-08-16T00:00:00
ID PACKETSTORM:25176
Type packetstorm
Reporter Simple Nomad
Modified 2001-08-16T00:00:00

Description

                                        
                                            `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" -  
- thegnome@nmrc.org - -  
- thegnome@razor.bindview.com - www.nmrc.org razor.bindview.com -  
  
-----  
  
_______________________________________________________________________________  
  
Nomad Mobile Research Centre  
A D V I S O R Y  
www.nmrc.org  
Adept [adept@anonymoushosts.net]  
Simple Nomad [thegnome@nmrc.org]  
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 secure@novell.com, 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.  
  
_______________________________________________________________________________  
  
  
`