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 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