On Wed, 10 Feb 1999, Darren Reed wrote: > In some mail from der Mouse, sie said: > [...] > > 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 ? Bannerchecking is a good example of this. But the problem is that banners are often changed to add an extra layer of protection, as many attackers rely on this to determine whether a box is vulnerable or not, to avoid "wasting time".. (Scriptkiddies does not though, since they try the exploit anyway, even if the exploit is written for a totally different architecture.. ;-) Why should a securityscanner do the same mistakes as an attacker often does? The determined attackers would find these holes.. > 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 ? This I agree with though. It all goes down to what methods you use to "determine" whether some attacks are useless to try, and if these methods can be relied on to make a conclusion on whether it's useless to make an exploit attempt. (Which I think the scanner should do, whenever possible) Another problem appears when one realizes that services not always is available on the same TCP/UDP portnumbers (SMTP obviously is though). Maybe this is changed for exactly the same reason as before, adding an extra layer of security.. And for local securitychecks, path/file names certainly can vary, this is a tough one to implement in a scanner satisfactory.. Cryptographical checksums is not of any use when the program was not from a binary distribution, but configured and compiled from source. This was not meant as criticism against Darren's posting. Rather some general opinions on securityscanners as a concept. > Darren / Joel Eriksson
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:34:10 PDT