Bugtraq mailing list archives
Re: ISS Internet Scanner Cannot be relied upon for conclusive
From: mouse () RODENTS MONTREAL QC CA (der Mouse)
Date: Wed, 10 Feb 1999 10:47:40 -0500
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 mouse () rodents montreal qc ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Current thread:
- Re: ISS Internet Scanner Cannot be relied upon for conclusive, (continued)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Joel Eriksson (Feb 12)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Randy Taylor (Feb 10)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Joel Eriksson (Feb 12)
- More Comments: Security Scanners. Craig H. Rowland (Feb 12)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Adam Shostack (Feb 10)
- remote fakebo shell exploit Groovy Pants Gus (Feb 11)
- AW: Security Bug in Bintec Router Firmware (CLID) Thomas Schmidt (Feb 11)
- Re: Security Bug in Bintec Router Firmware (CLID) Pascal Gienger (Feb 11)
- Seeking Policy Data Loftin C. Woodiel (Feb 11)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive David LeBlanc (Feb 09)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive der Mouse (Feb 10)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Ulf Munkedal (Feb 10)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Brian Koref (Feb 11)
- Buffer overflow in Serve-U Ryan Sweat (Feb 11)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Phil Waterbury (Feb 11)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Francis Favorini (Feb 12)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Steven M. Christey (Feb 12)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Daniele Orlandi (Feb 13)
- Re: ISS Internet Scanner Cannot be relied upon for conclusive Shaun Lowry (Feb 15)