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 dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:04 PDT