[24353] in bugtraq
Security issue with GroupWise 6 and LDAP authentication in PostOffice
daemon@ATHENA.MIT.EDU (Frank Bulk)
Wed Feb 20 22:02:12 2002
Date: 20 Feb 2002 22:43:51 -0000
Message-ID: <20020220224351.29885.qmail@mail.securityfocus.com>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
From: Frank Bulk <frnkblk@iname.com>
To: bugtraq@securityfocus.com
Issue: Any user can login into any GroupWise
account.
Environment: GroupWise 6 Post Office using LDAP
authentication AND security configuration of
PostOffice leaves LDAP User Name and Password
fields blank in the Post Office Agent object in
ConsoleOne.
Exploit: Run GroupWise as any user
(either "grpwise /@u-?") OR if you are not NDS
authenticated, whatever the registry has stored as
the last person who logged into GroupWise) and
leave the password blank. Hit enter a couple of times
and you will get right into the account.
Details: TID 10067921 should be posted as it shows
the steps you need to take to leave LDAP
authentication on, and not have the password
problem. When I spoke to the technician on the 14th
it was supposed to have been posted, but it hasn't yet.
Fix:
A. Novell has developed a workaround to this issue
in the LDAP spec to prevent GroupWise accounts
from being accessed without a password. This fix is
found in the Field Test File FGW62N4.EXE. This can
be found at support.novell.com and searching for the
filename.
Pro: solves problem, retains current password
functionality.
Con: New code comes with possible stability issues.
B. Without implementing the new code, the issue
can be resolved as follows: Fill in the LDAP User
Name and Password fields in the Post Office Agent
object in ConsoleOne. The LDAP User Name is the
eDirectory account that the POA, the Internet Agent,
and the WebAccess Agent can use to log in to the
LDAP server in order to authenticate GroupWise
users.
Pro: this approach to LDAP authentication is faster
and requires fewer connections to the LDAP server
than if each GroupWise user authenticates to the
LDAP server individually.
Con: From within GroupWise, users will not be able
to use grace logins, nor will they be able to change
their LDAP passwords.
Technical details (in Novell's words): This isn't
technically a bug, but a configuration issue. In
accordance with the LDAP v3 RFC 2251, an LDAP
bind in which a username is provided but a password
is not [ie. blank] is treated as an anonymous bind.
This means that a bind is granted to users providing
a username but no password. The bind granted is an
anonymous bind but, based on limitations in the
LDAP spec, most LDAP implementations do not
provide any indication that the bind is in fact
anonymous. GroupWise relies on the success or
failure of a bind to determine whether a users
username and password is authentic when LDAP
authentication is being used [if you put LDAP trace on
you will see that blank password become anonymous
binds]. The problem is in the RFC, not GroupWise.
Once we realized that RFC had the hole, we made a
change in the POA. This problem only came to our
attention about 2 weeks ago so it takes time for
information to get out.
Remaining question: How come the Padlock fix was
so heavily advertised (read: spammed) and this
major hole was open? Why didn't the FTF make a
bigger deal of it?
