Re: Security Hole in Axent ESM

[reddog () BLKBOX COM (reddog)]

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 <sjackson () AXENT COM>
To: BUGTRAQ () netspace org

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