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