[9467] in bugtraq

home help back first fref pref prev next nref lref last post

Security Scanners and other Auditing Tools [was Re: ISS Internet

daemon@ATHENA.MIT.EDU (A. C. Eufemio)
Thu Feb 11 12:24:54 1999

Date: 	Tue, 9 Feb 1999 13:19:40 -0800
Reply-To: "A. C. Eufemio" <anthony_eufemio@YAHOO.COM>
From: "A. C. Eufemio" <anthony_eufemio@YAHOO.COM>
To: BUGTRAQ@NETSPACE.ORG

> If ISS claims to check for the ioslogon bug, but actually checks (by
> whatever means) for software versions known to have that bug, the
claim
> is a lie.

I would not go as far as saying that it is a lie.  It's just dubious and
just gives the security auditor inadequate data during the audit
process.

> If you claim to check for the ioslogon bug, then that's what
> you should do: try to exploit it and see if it works.  Who knows,
maybe
> there's another vulnerable version out there, or perhaps some
> supposedly vulnerable versions don't happen to be vulnerable after
all.
>

All security scanners and intrusion testing software should actually
exploit
the vulnerability that they are testing for to determine if it is
actually
vulnerable.  Audit reports should not be generated using security
audit tools
that only check for vulnerabilities based on the version number and
patch
levels but instead use this information generated by tools like ISS,
strobe,
COPS, NetRanger, etc. as a guideline as to what resources need further
testing
and investigation.  The reason for this is that there may be some
security
program that might actually prevent vulnerability exploitation from
happening.
A good example of such security program is SeOS Access Control for
UNIX.  This
product is used by many big companies to protect specified resources
even if UNIX
permissions allow access and it can also protect the resources from
root.  With
this in mind one can use a security auditing tool to check for the
vulnerability
by relying upon the version number of the operating system and the
patch level
it has and it could potentially identify resources as being vulnerable
even if in
fact the resources have an added layer of protection that the security
scanner does
not recognize because it is not part of the native operating system's
security.

For more information about SeOS Access Control and SECURED check out
http://www.memco.com/ there is also a product that prevents stack
overflow exploitation on several UNIX platforms.

> I can't remember offhand what this bug does.  If it's a "hang your
> router" sort of thing, you may want to have *two* tests, potentially
> independently controllable, "check for ioslogon bug (dangerous, may
> crash your router)" and "check for software versions known to have
> ioslogon bug (safe, requires SNMP)".  But claiming to check for the
bug
> when actually just checking the software version (via a means which
can
> be disabled without closing the bug, no less) is like a spamfighter
> saying "your SMTP daemon claims to be an old Sun sendmail, therefore
> you're an open relay": it's checking for the wrong thing



>> OK, so maybe you can explain just exactly how we're supposed to find
>> out whether it is vulnerable if it won't talk to us?

Perhaps actually exploiting the bug would tell you if the system is
vulnerable.

==
-=-=-=-=-=-=-=-=-=-=-=-=-=-
     Anthony C. Eufemio
 anthony_eufemio@yahoo.com
-=-=-=-=-=-=-=-=-=-=-=-=-=-

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

home help back first fref pref prev next nref lref last post