Hi, (This is long, but please bare with me) I am sorry to bring this up, but it seems that there are too many "trickle though" cases where Nessus will cause false positives when trying to access pages that are not answering a "404 File not found" response. As far as I can see: http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-plugins/scripts/n o404.nasl And http://cvs.nessus.org/cgi-bin/cvsweb.cgi/~checkout~/nessus-libraries/libness us/www_funcs.c Won't handle cases such as: 302 Found (As used by some firewall, IDS, etc, to redirect to a "caught you page"), 400 Bad Request (Caused by incomplete requests, for example certain access to file parser cause it, file parser that capture all incoming request and handle them, i.e. even accessing /foobar will cause this error), 401 Unauthorized (Username required), 403 Forbidden (IP limited hosts), 500 Internal Server Error (Very similar to the one for bad request, usually due to an internal server misconfiguration, but causes false positives), 503 Service Unavailable (This is very silly, I know, but still obviously Nessus falls over it). I would conclude that one of the two should be done: www_funcs.c should be modified to unly rely on no404's findings, not implement its own reparsing such as in the case of "301 Moved Permanently", but rather only do that if: 1) no404 failed to find any recognizable pattern. 2) it is obvious that the reply was a valid one (this is a tricky part, but making the (1) part as best as possible will reduce this). no404.nasl currently doesn't detect such problems well because: 1) The case sensitive fails sometimes, I can't figure out why, and Renaud didn't to have yet come to fix it. 2) It only checks for: 1) title repeat 2) not found string. 3) 404 string. What should be added to no404.nasl? (as far as I can see) 1) File requested reply (something of the sort of "Location: /error.htm?file=requested_filename_by_nessus") 2) 401 Authorization Failed on everything (even on access of "/") or any other HTTP response for multiple requests, even valid ones.. such as "/". 3) Any others? Why I am contacting you? Because I can 100% and still miss a lot of things, different servers, might make it false positive, or maybe you even can think of a different better test? What will happen if nothing is done? The amount of false positives will grow each time new CGI tests are added, scans for: 1) Multiple hosts will show more false positives than usual 2) Webmin, Apache/IIS (IP Secured and Username Secure), etc will show all possible false positives for server based scans. 3) Value given by scanning for selective CGI names will drop, plugins will need to be custom tailored for each exploit, i.e. you will not be able to trust is_cgi_installed() turn return a valid answer for a known CGI filename that contains a vulnerability, but will rather need to exploit the remote CGI (breaking the idea of Safe Checks). Thanks Noam Rathaus http://www.BeyondSecurity.com http://www.SecuriTeam.com
This archive was generated by hypermail 2b30 : Sun May 05 2002 - 12:41:23 PDT