>> 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. > Let me hit you with another suggestion: if you know something about a > box which suggests that an attack won't work, why try it ? Because the suggestion can be wrong. > For example, if I do a port scan and cannot connect to the smtp port > and later amongst the list of things to check are various sendmail > bugs, should I still try them ? If you have some other access to sendmail, yes. If not, then it's not just a "suggest[ion]" that the attack won't work; it's *certain* that the attack won't work. If you have prior information that tells you it *can't possibly* work, don't bother. If your prior information merely says it *probably won't* work, it's still worth trying. At least for a heavy scan. > The expectation is that if a service is meant to be available, that > it will at any time of a scan. If a service is not available then > more than likely there is no point making further advanced checks. Right. But the ioslogon bug does not depend on SNMP being available, so SNMP being unavailable should not be taken as an indication that the attack won't succeed. Now this particular bug is an interesting case, because (I gather) it is not possible to exploit it without doing damage. Some attacks (for example, those which just get you a root shell) can be tried without doing damage; with such attacks, there is no reason ISS (or moral equivalent) shouldn't just try them. In cases like this, it should be done only when specifically configured to do so, and when not so configured, it shouldn't make any claim either way. (Here, if it can coax a software version number out of the box, it would be reasonable for it to spit out a "appears probably vulnerable" or "appears probably not vulnerable" indication, or "can't tell" if it can't. This is not the same thing as a definite vulnerable/not.) der Mouse mouseat_private 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:45 PDT