No idea if this is what the Groupwise Padlock
(https://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
https://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 https://www.nmrc.org/advise/nds1.txt and
https://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 (https://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.

_______________________________________________________________________________