Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: Security Hole in Axent ESMreddog (reddogBLKBOX.COM)
Sun, 30 Aug 1998 08:08:48 -0500
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: M.C.Mar: "Re: Buffer overflows in Minicom 1.80.1"
- Previous message: Willy TARREAU: "Re: buffer overflow in nslookup?"
- Maybe in reply to: dcuppSNAKEBITE.COM: "Security Hole in Axent ESM"
- Next in thread: Andy Church: "Re: Security Hole in Axent ESM"
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 <sjacksonAXENT.COM> To: BUGTRAQnetspace.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