[9413] in bugtraq
Re: ISS Internet Scanner Cannot be relied upon for conclusive
daemon@ATHENA.MIT.EDU (David LeBlanc)
Mon Feb 8 13:03:38 1999
Date: Mon, 8 Feb 1999 11:02:45 -0500
Reply-To: David LeBlanc <dleblanc@MINDSPRING.COM>
From: David LeBlanc <dleblanc@MINDSPRING.COM>
X-To: "Mr. joej" <mr_joej@HOTMAIL.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <19990208022855.7136.qmail@hotmail.com>
At 06:28 PM 2/7/99 PST, Mr. joej wrote:
>Example 'Router Checks' I wanted to scan my network to see
>if I had any routers that were vulnerable to the old
>ioslogon bug. After a quick scan, I found none. I knew
>this wasn't right, there was one somewhere I hadn't upgraded
>yet. After testing by hand I found it. I talked to ISS about
>this for a while, after sending logs and talking to the engineers
>their reply was 'well snmp is disabled ....' The rest of their
>reply was something about how this vulnerability was related to
>snmp therefor Internet Scanner couldn't scan for it. This is WRONG.
There appears to be some misunderstanding on your part. As I'm sure you're
aware, there are often several different ways to check for a given problem.
Sometimes we check for the same hole using more than one method, and in
other cases, we don't have _all_ the methods which are possible. It is
certainly our goal to have a totally comprehensive, perfectly reliable
network auditing tool, but given the rate at which new bugs come out, the
number of programmers we have, and the fact that they need to sleep once in
a while, it might take us a bit longer to achieve perfection. Sorry if
someone was confused and told you that the _bug_ was related to SNMP - our
detection method certainly utilizes SNMP.
One of the ways to check for this particular bug is to us SNMP to pull down
the sysDescr information, and parse it to look for versions that we know
have problems. _If_ we can get the system description, it is an easy and
reliable way to find vulnerable machines. However, if SNMP isn't running,
or won't respond (even after trying to guess the community string), then
this method won't work.
>After some testing this is what was found. Internet Scanner only
>tests for this bug if it can either gain access to a shell (by
>guessing the telnet password), or by getting snmp access to get
>the IOS version information. Based upon this, Internet Scanner
>determines whether or not the router is vulnerable. This is WRONG.
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? I'm certainly no router
expert (being an NT geek), so if this can be done in some other way, we'd
be really happy to know what that is so that it can be included in a future
version. Sounds to me like we're certainly TRYING to find the hole a
couple of different ways. If we're faced with finding the problem at least
some of the time, vs. not finding it at all, I'll take partial success over
no check at all. OTOH, once we know of more and better ways, I'm all for
including them as soon as we can.
>This same holds true to all router checks except ascend udp kill.
>My follow up question, How many other vulnerabilities does Internet
>Scanner say it will scan, but really doesn't?
If we say we check for something, and we try at least one method of
determining if that bug is there, then we're scanning for it. There are
several vulnerabilites we check for in some manner where we don't exhaust
_all_ the possible methods. It could be due to a number of factors - we
might not know of something - I keep learning new things all the time, and
we're good, but certainly not omniscient. It might also be technically a
PITA to check something, or it could be that we just did as much as we
could in the time we had.
I'll give an example from the NT side of things (since I wrote that code) -
we have a check for multi-homed NT boxes. We used to check for this using
the registry, and up until registry access got restricted most of the time,
it worked really well. When I was doing the 5.6 re-write of the NetBIOS
checks, I found a way to always get that information from a NULL session,
so that's what we use now. It will work until NT 5.0 changes things, and
so it goes. We certainly checked for it, but once we figured out a better
way, we used that.
If there is anything we claim to check for that just plain doesn't work,
that's called a bug. Let us know what is going wrong and we'll fix it. If
we're not using _all_ the methods you're aware of to look for a given hole,
then by all means let us know, and we'll take that as an improvment
suggestion.
David LeBlanc
dleblanc@mindspring.com
