Forwarded From: "Jay D. Dyson" <jdysonat_private> Originally From: "Dr. Mudge" <mudgeat_private> Originaly To: BUGTRAQat_private In the SAFER bulletin they mention compromising software that was explicitly installed as an additional security measure. While joking around I was mentioning to some colleagues about the attrocity of some (most) of the security related products out there right now. Not in what they are claiming to accomplish but in the lack of sound coding in their own products. I thought it was pretty much understood but the amazed looks on their faces told me otherwise. So I figured I might point this out in case that was not an isolated assumption that these people had. Hopefuly I'm already preaching to the choir on Bugtraq. [Note - though I explicitly mention ISS and Axent they are by no means any worse or better than others not mentioned here... in addition I am referring to older versions of their products. I have not spent time looking at their most current releases to verify whether things have improved or gotten worse. Please take this for what it is meant to be - a general rant about the security vendor world as it stands... not an attack against particular vendors] A few real world cases: A few revs back in ISS' commercial security scanner there were several vulnerabilities. One particular company contracted me to come in and give them a report on the level of competance that an auditing company they had hired were at. Sure enough, when the auditor scanned the box that we had setup they were using ISS (version 3? my memory isn't serving me very well right now). Upon an attempt to connect to tcp/79 (fingerd) we fed them back a bunch of 'garbage' (well, you know... that garbage that is comprised of a long run of NOPs followed by machine dependent opcodes and operands :). After a few tries, root on the scanning machine was handed out as there were no checks done on the data that was being retrieved (or more accurately assumptions were being made about the length). ... Axent swore up and down that their ESM systems were communicating via DES encrypted channels. In reality the communications were simply XOR'd and they would send the progressive XOR key every X packets. The DES components were slated for the 'next rev'. Doesn't matter - the point is that they shouldn't have done the XOR scheme to begin with when the purpose of the communications between the client and server are "lists" of vulnerabilities on said machines. Not something you want advertised to anyone passivle monitoring. ... I don't know how many "security" packages I've looked at that do outrageously stupid things like chmod(777), popen(), or system() even! Even if the program is running non-priveledged and is designed to be on a system that does not have multiple users it is a demonstration that the people writing the code to protect your systems (often at outrageous price tags!) seem incapable of demonstrating sane coding techniques themselves. How is one supposed to get 'warm fuzzies' that one is having their systems "protected" when the products doing the protecting show no security competence. Vendors listen up! .mudge -o- Subscribe: mail majordomoat_private with "subscribe isn". Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:13:23 PDT