Re: Re: Recent bugtraq postings -- MIDRANGE-L

Patrick,

You said that
>    Implied by the posting: OS400 will provide anyone who knows how to
>    talk to an LDAP server information about user profiles on the system.
Here is the actual quote from the posting:

"To conduct such a search, you need any valid AS/400 account.
The LDAP search ability is not dependant on any restrictions or
special permissions the user may have.
The search returns information about user profiles that are in the
same group like the account we use for the exploit, and this situation
is common enough in the legacy applications world."

Nothing implied, just straight facts.

Consider a typical BPCS installation. It has a few dozen to a few hundred
users, all belonging to the same group.
>From a security point of view, a shipping clerk with limited interactive
capabilities and no authority to WRKUSRPRF should not be able
to extract a list of the other users even if they belong to the same group.
The "Implementing AS/400 Security" book dedicates a couple of pages just for
a discussion of how to name user profiles so they are difficult to guess.
Knowing other users names is bad for system security.
Once the user names are known, LDAP can be used to conduct a dictionary
attack,
and LDAP has no exit programs to create automatic alerts upon invalid login
attempts.
LDAP provides yet another thing to worry about.

>
> I don't know much about the OS400 POP server. As far as I know, the OS400
> POP server is not used by a wide range of OS400 customers...
>

Then why is it shipped and turned on by default?
Because of the informative messages it provides, POP3 can be used for a
phonebook attack to guess at the user base.
Again - no exit programs are available.

Shalom Carmel
----------------
www.venera.com - Exposing iSeries insecurity


----- Original Message ----- >
date: Mon, 25 Apr 2005 12:27:31 -0500
from: Patrick Botz <pcbotz@xxxxxxxxx>
subject: Re: Re: Recent bugtraq postings

>
> These are my opinions only. They do not necessarily reflect the opinions
of
> my employer...
>
> Just a couple examples of inaccuracies
>
>    1. Claim: The LDAP server on OS400 provides information about userIDs
>    on OS400. The LDAP server is started automatically. Both are true.
>    Implied by the posting: OS400 will provide anyone who knows how to
>    talk to an LDAP server information about user profiles on the system.
>    False/wrong/inaccurate.
>
>
>    Clarification: OS400 in general -- not LDAP on OS400 -- allows a
>    person to see those user profiles to which they are authorized on a
specific
>    system. The LDAP server provides the same information that other OS400
>    interfaces will provide based on authorization.
>
>    This is NOT a problem related to LDAP and characterizing it as such is
>    inaccurate. This is an architected and documented behavior of the
system -- 
>    not for LDAP but for any interface related to list user profiles that
exist
>    on the system. Sending people off to look for an LDAP exposure wastes
time
>    and energy and takes focus away from things they could be doing to
manage
>    the security on their systems better.
>
>    The LDAP server is started by default, however, unless it has some
>    PUBLIC information stored in it (access allowed to anyone that binds),
there
>    is nothing to see. The fact that an authenticated OS400 user can see
the
>    same information through LDAP that they could see through any other
non-LDAP
>    interface to look at the same type of data does not necessarily
constitute a
>    security exposure.
>
>    The recent public postings implied that not only is the LDAP server
>    started by default, but that somehow the information about other
profiles on
>    the system is available to anyone that knows the TCP/IP address of the
LDAP
>    server. Only authorized OS400 user profiles are allowed to access the
>    "projected user profile" LDAP back-end. Even when authorized the
profiles
>    can only see those other profiles to which they are authorized.
>
>    If one doesn't agree with the documented behavior, then they should
>    provide the necessary information to the vendor (not to mention read
the
>    documentation which is on-line in the information center). I personally
do
>    not consider this a security exposure; however, if you believe it is no
>    longer considered appropriate then work to change it through the vendor
who
>    is the only one that can. Publishing inaccurate information in a public
>    forum is not an efficient way to influence change.
>
>
>    Again, seeing any data to which you are authorized is not considered a
>    security exposure. On OS400, as opposed to those systems you might
actually
>    use, user profiles are separate objects (it's an object-based OS).
Since a
>    user profile is an object you have a level of authorization control
over
>    them that is not typically available on other systems.
>
>    Because the public announcement only noted the LDAP server, a lot of
>    people went on a hunt to try to find something they were not likely to
find.
>
>
>     2. Claim: OS400 has a security exposure because a bad person could
>    use commands on OS400 to do bad things on Windows.
>    Implication: OS400 causes the exposure.
>    Clarification: The fact that you can use information from a connection
>    established by windows to perform windows commands unrelated to the
>    connection is not an exposure of another system that "COULD" take
advantage
>    of it. It is a windows exposure. It's something that needs to be
managed or
>    fixed in Windows.
>
>    Announcing it as an OS400 exposure is inaccurate and helps no one
>    address the real "issue." The implementation of commands on OS400 use
the
>    same mechanisms on the windows side as could be used from any other
system.
>
>     3. Claim: IFS is not protected by 3rd party vendor products...
>    Implication: IFS cannot be protected. Whether intended or not, this
>    was the implication, and this is totally false.
>    The short description of IFS implied that by it's mere existence on
>    OS400, that there was some kind of "undesirable" security attribute. It
is
>    easy to use OS400 as a file server for windows, but it can just as
easily be
>    configured to only share files in a particular part of the IFS file
system
>    tree or subdirectory of a particular file system tree.
>
>    Is it possible to incorrectly file server more files than intended?
>    Yes. Is this a security exposure for the system? No? Is it a security
>    exposure for 3rd-party applications? I don't know, because since I
don't own
>    or use those applications, I cannot be certain how
>    they are configured and if they are configured correctly. However, it
>    is not clear that if the observed behavior was related to exposures in
3rd
>    party products or due to the way a particular implementation of one or
more
>    of those products. Without a copy of the product and documentation, I
don't
>    see how anyone could ascertain whether observed behaviour is an
inherent
>    exposure in the product. At best, one should clarify whether they have
>    actually tried each product AND whether the problem was known NOT to be
a
>    configuration problem.
>
>     4. Claim: "IBM refused several times to answer my queries about some
>    of the
>    issues. I was asked to supply a valid service agreement before anyone
>    would talk to me."
>    Implication: IBM will not accept input related to security exposures
>    Clarification: The IBM support line DOES accept input related to
>    security exposures. If you do not have a support line agreement you can
only
>    use the interent interfaces; you are not entitled to phone support.
>
>    There is no way IBM could provide phone support to customers that
>    actually pay for their systems and presumably understand how their
system is
>    configured if they spent time with those people who haven't apparently
>    purchased a system.
>
> It is irresponsible, in my opinion, to publicly report a security exposure
> when one does not totally understand the system or applications for which
> they are reporting an exposure. It is also irresponsible not to get
> independent verification of a suspected exposure -- especially if one does
> not even know how the system being tested is configured with respect to
> security.
>
> I don't see how it is possible to determine whether a security exposure is
> inherent to a whole class of systems or merely due to the way a particular
> system is configured or managed if you don't have access to someone who
can
> report an APAR. To not mention in public postings that the vendor was not
> notified because you are not a customer is also misleading, in my opinion.
>
>