Re: ISS Internet Scanner Cannot be relied upon for conclusive

[rtaylor () MAIL CIST SAIC COM (Randy Taylor)]

At 10:06 AM 2/9/99 -0500, der Mouse wrote:
> > > [...] the old ioslogon bug [...ISS didn't find it...]
>
> > [...response from someone who writes as if on behalf of ISS's makers;
> > I can't recall whether mindspring.com is the ISS people or not...]
>
> 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.  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.

[Noting up-front that I'm not an ISS apologist - I prefer CyberCop. ;]

One of the hard lessons I learned long ago when writing vulnerability
testing code is that exercising exploit methods can do more harm than
good. A crash or a system lockup may be the result, even though the code
was written to avoid such a thing. In other words, stuff can and often does
happen.:-}

Checking for software versions that are known to be vulnerable to some
type of attack without actually exercising the associated exploit is a
legitimate and non-destructive test method. A subsequent marketroid claim
is also legitimate, IMHO, provided the test report output says something
to the effect of "...this system may be vulnerable to the XYZ attack...". I
would prefer that the word "may" be emphasized in the report, but that's not
always the case. In the end, no commercial vulnerability testing tool can or
should substitute for good old-fashioned human analysis of the post-test
report.

> 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?
>
> Surely this is a bit of a no-brainer - why not just try the exploit and
> see if it works?  That's certainly what an attacker will do.

Some exploit methods can be exercised safely in a vulnerability testing tool
and some can't. For instance, I've found that the old sendmail bounce
attack (password file grab) can be done pretty safely, whereas checking
for open X displays can crash or lock up some types of X Terminals.

While I agree an attacker will most certainly attempt a full-blown
exploit, the attacker has no liability in the corporate sense. A commercial
testing tool like ISS or CyberCop does have such a liability. ISS and NAI
have relatively deep pockets, and must exercise due diligence and care in
the methods used by their products to test for vulnerabilities. No one would
buy their products if they crashed or locked up systems on a regular basis.
Crackers have shallow pockets (or none at all ;), and no such concerns for
diligence or care.


>                                       der Mouse
>
>                              mouse () rodents montreal qc ca
>                    7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Best regards,

Randy
(speaking only for myself)


-----
Randy Taylor
Senior Infosec Engineer
SAIC Center for Information Security Technology

email: rtaylor () mail cist saic com
       joseph.r.taylor () cpmx saic com

phone: 410-872-4883
fax:   410-872-0107