Re: Security Hole in Axent ESM

From: reddog (reddogat_private)
Date: Sun Aug 30 1998 - 06:08:48 PDT

  • Next message: Andrey Alekseyev: "Re: FreeBSD's RST validation"

    To all;
    
    First, let me apologize, as this message does not speak directly to the
    "security" issues of Axent it is more about the basics.  And second,
    thanks to the two guys on my 'old' team, as they did most of the problem
    determination regarding Axent.
    
    Now, ESM 4.4 must be able to be spoofed which is the reason Axent
    included MD5 in 4.5, correct? Yeah, that is what I thought.  Now for a
    more fundamental problem...
    
    Too many times in a complex distributed network (UNIX, NT, NDS, etc...)
    senior management will attempt to find a "single solution" to all of
    their security problems, e.g. Axent ITA & ESM.  Unfortunately, what ends
    up happening is the tool decided upon is not the best, or even close to
    the best, therefore "things" get sacrificed.  These things are,
    usability, functionality, robustness of a product, and yes security.
    
    A perfect example of this is when you install and run ESM on a Solaris
    2.6 system with SAMBA configured, you get a message from the Axent
    security report stating your "registry" is vulnerable to an attack
    because you have NetBIOS running on your system.  This is a perfect
    example of the products "dead head" approach to programming.  (Axent
    here is a tip)  Why wont the application pass a variable like "uname"
    and if it is not a UNIX based product don't report about the
    "registry".  It would go a long way in lending credibility to your app.
    with the technical community.
    
    Next, comes ITA...  this application is such a pig we had a 40% increase
    in SQL statement response times with this package running on AIX 4.2 and
    Oracle 7.2.2...  I know you all will say, you can tone down what you are
    monitoring in "real-time" with ITA where this 40% increase, or
    degradation performance will not occur...  Well if that is the case why
    do I need Axent ITA?  Why not use a much "cheaper" (free) solution like
    Tripwire?
    
    For what it is worth my opinion is, use the tools for the OS's for which
    they were designed.  In most cases you will get much better performance
    with greater security.
    
    reddog.......
    
    PS.  There are two more products that come with Axent...(URM & UPM)
    Stay tuned for more problems...
    
    ------------------------------------------------------------------------
    
    Subject: Re: Security Hole in Axent ESM
    Date: Fri, 28 Aug 1998 10:36:53 -0600
    From: Steve Jackson <sjacksonat_private>
    To: BUGTRAQat_private
    
    Let me address a couple of items pointed out in prior email concerning
    the
    ESM (Enterprise Security Manager) product from AXENT Technologies.  For
    those of you that may not be fully informed about the AXENT product
    line,
    ESM is a security assessment tool that allows customers to assess their
    current network-wide security readiness.  This tool allows a security
    administrator/auditor to evaluate where the potential security holes are
    in
    their environment across multiple platforms within their enterprise.
    All of
    this data can then be rolled into a single enterprise report
    automatically.
    Now with that base information... the details about the issues:
    
    The CRC check is used in conjunction with other checks by ESM to
    determine
    when a customers file has changed.  The usage of CRC as a method of
    checking
    for file change while not the most robust method does not constitute a
    hole
    in ESM as there is no way the use of this method would allow someone to
    gain
    access to ESM.
    
    We at AXENT agree that CRC checks are not as secure as our customer base
    
    would desire.  Thus, we have added the MD5 (128 bit) check to ESM.  This
    
    shipped in the ESM 4.5 product in March of 1998.  Now our customers can
    choose to run either CRC or MD5 according to their needs.
    
    I want to respond to comments regarding the use of XOR within ESM 4.4 as
    a
    method of hiding communications between servers and remote clients.  I
    would
    like you to know that the method employed is not just XOR logic, but XOR
    
    combined with standard 40 bit data hiding technology.
    
    We at AXENT recognized that this methodology was not as secure as
    desired.
    We have enhanced the communications security between servers and clients
    to
    utilize a Diffie-Helman key for the session, combined with encrypting
    every
    packet across the wire using DESX encryption.  This has been available
    since
    ESM 4.5 shipped in March of 1998.  In addition to this, communications
    handshaking occurs at the initiation of every communication sequence
    between
    client and server.
    
    Steve Jackson
    AXENT Technologies
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:24 PDT