Re: ISS Internet Scanner Cannot be relied upon for conclusive

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 09:46 AM 2/8/99 PST, Mr. joej wrote:

> I never called it a 'bug'.  I called it a misrepresentation.  Example:
> You test for the OOB or winnuke DoS.  Do you retrieve the OS version,
> and look for vulnerable versions? NO, you actually test it.  Hence the
> test is pretty reliable.
>
> However---
> With the cisco router checks, if I have them selected, I scan my network
> and Internet Scanner cannot gain access to the box via snmp or user exec
> mode, then it will not report anything about these tests.  It doesn't
> say I'm vulnerable.  It doesn't say I'm not vulnerable.
> Refering back to the OOB test, why don't you just scan for these tests
> to? the ioslogon bug in particular?

Glad you brought up the OOB test.  That's an interesting case.  Actually,
what we do is first attempt to determine from file versions whether the OS
is vulnerable, and if we cannot determine the file version (say due to lack
of access), and you have enabled the actual attack, then we perform it (and
if we do find out it is vulnerable, we refrain from crashing it just to
prove the point).  There are a bunch of NT patches we check for by file
version - for example, we don't actually get on the machine and run
getadmin to see if it is vulnerable.

Consider another interesting case - there are several sendmail exploits
(circa 8.6) which require hardware and platform-specific eggs.  We
obviously would have a hard time actually implementing these, and it would
be very difficult to make it reliable - so we do a banner check.

In terms of "actually test", I have to argue with your language - anything
that can determine whether a system is vulnerable is actually testing.
Note that nearly all methods are prone to error - for example, I could tell
you that a machine is vulnerable to some sendmail exploit, and you now go
and test it with some script - the script says it isn't, but it is because
the script was written for x86, and the machine is really running on Sparc.

As I said in the previous mail, I'm pretty clueless about router stuff, so
I'm not familiar with this particular bug - if there is a better, more
conclusive way to test for this specific vulnerability, let me know what
that is, and I'll do my best to get it into the product.  However, IMHO, we
didn't have a way to find this at all prior to 5.4, so at least finding it
some of the time is better than never finding it.  Obviously, we'd like to
find it _all_ the time if it is there (I personally find false negatives
most egregious), so if we can improve, then that's a good thing.

> AND----
> if you don't know how, and the only way for you to scan is looking at
> the version, at least tell us (Internet Scanner users) that 'hey I
> couldn't scan for these bugs for reason .. .blah blah'

That would get a little verbose, don't you think?  We currently check for
about 500 things (even I've lost count), so if I started telling you that
we couldn't find any of 200+ NetBIOS vulnerabilities because I can't open
port 139, I think you'd get annoyed.

Something that would be helpful for a skilled user such as yourself would
be to get familiar with the log files.  We print all sorts of debugging and
verbose output to the logs - you can very quickly determine from the log
whether it got the information or not - and usually why it didn't get the
information.  In fact, the explanation of _why_ you didn't find this
particular bug was in the log file.

> now granted I don't care to see that you couldn't scan for NFS problems
> on my router.  There would be no point.  But you definitely need to
> figure something out!

Sure - it would be nice to have more of these things documented, and that's
a suggestion I can pass along to the tech writers.  Documenting something
like the scanner thoroughly enough for all the users is a daunting task - I
wrote a lot of the documentation for a while there.

> once again, pointing out this is not bashing any product, I like ISS
> Internet Scanner, however this is something they did not want to address
> directly with me, nor did I think anyone else would be aware of this.

I felt fairly well bashed, so...  I apologize that you didn't have an
optimal experience with tech support, but in general if you point out that
we have a false negative, and it is because we're not using all the methods
we might have available, then please tell us how we can make it work
better.  If we can manage to get it into the product, we will.

I also think it is important to recognize the limitations of any tool
you're using, whether it be a yardstick or a scanner.  We cannot possibly
use every available method for every bug out there.  It is tough enough
trying to keep up with new things coming out, along with expanding our
scope to new products and types of devices.  In the case of routers, I
think we could add a lot of functionality in that area.  Adding these SNMP
checks was a big improvment over what we had before - but there is
obviously still a lot of work to be done.  No rest for the wicked 8-)


David LeBlanc
dleblanc () mindspring com