Re: Re: Recent bugtraq postings

The following are my opinions and do not necessarily reflect the opinions of 
my employer.

I won't argue whether a user should SHOULD or SHOULD NOT be able to see user 
profiles to which they are explicitly authorized. I actually agree with you 
that the legacy design of the system that causes user profiles to have 
exlicit READ authority to other members of the group should be looked at by 
IBM. I've never denied this behavior exists. It is also not what makes this 
particular posting inaccurate. 

What's inaccurate is:

   - Somehow LDAP is the cause of the problem. This is clearly 
   inaccurate. Your post clearly only discusses LDAP and implies that somehow 
   LDAP is the problem. If you are concerned about an authorized user of the 
   system being able to see data (user profiles in this case) to which they are 
   explicitly authorized, then LDAP clearly is not the problem. 
    

   - You state "the LDAP search ability is not dependent on any 
   restrictions or special permissions the user may have." This is clearly 
   inaccurate. An LDAP search operation on the LDAP projected user profile 
   portion of the LDAP tree will not return any user profiles to which the user 
   profile under which the search is done is not explicitly authorized. Your 
   posting, whether intended or not, strongly implies that one only need 
   authenticate via LDAP to see any user profile on the system. Implying 
   therefore a much larger issue than one you have "uncovered." 
   
    - You state "Once the user names are known, LDAP can be used to 
   conduct a dictionary
   attack," Again, while absolutely true, without also stating that the 
   dictionary attack can only be mounted by an authorized user (who could use 
   any of a number of other interfaces on the system to mount the same attack), 
   you imply that this is an "exposure of LDAP." 
   
    - Assume for the moment, that this behavior was only available in 
   LDAP. Posting to bugtraq itself was misleading. Advisory services such as 
   CERT and Bugtraq are inteneded to be used to notify the public of exposures 
   inherent to a system that are neither obvious nor easily avoided. While it 
   is laudable that one would try to inform the public about common 
   configuration issues and mistakes, much of what you have reported falls into 
   the "if you don't manage explicitly manage the security of your system, your 
   not protected" category. Posting this sort of information on these sorts of 
   sites is inherently misleading, in my opinion.
   
    - A previous append of yours stated that you "tried to talk to IBM 
   but they wouldn't talk to you without a customer number" is also misleading 
   -- intentionally or not. Had you done a bit of homework before hand, you 
   should have easily found the details behind IBM's phone- and web-based 
   support-line contracts AND the web-based software support site where anyone 
   can report any bug without a support-line contract. I have never used the 
   web-based support before so I had to spend about 2 minutes to find
the URL: OS400
   and i5OS 
support.<http://www-912.ibm.com/supporthome.nsf/document/32244842>Whether
you care for the rigamoral involved is not justification for
   implying that IBM would not accept the input. But I don't believe that 
   eliminates the responsibility that anyone has for notifying and working with 
   the vendor to fully understand and provide all of the details. 

In my opinion, a security expert should
one should verify that they understand the entire nature of a suspected 
exposure, report it to the vendor of the product that can actually fix or 
change the behavior, report problems 

On 4/25/05, Shalom Carmel <shalom@xxxxxxxxxx> wrote:
> 
> 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 <http://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.
> >
> >
> 
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
> 


-- 
Pat Botz
pcbotz@xxxxxxxxx