Mailing List Archive: Whisker Research

Whisker Research

Oct 30, 2003, 10:50 AM

Post #1 of 5 (755 views)

We are noticing that the whisker plugin (ID=10845) has been the main
source of false positive CGI abuses. I think I found out why it is
raising so many false positives for us:

It depends on no404.nasl. If no404.nasl detects that the server is
"broken", then the whisker plugin aborts with no threats found,
which sounds fair. The problem is that no404.nasl does not treat
"403 Permission Denied" requests as "found" while whisker does.

Here are the changes that I would like to make:

Make no404.nasl store something in the kb when it gets 403 return
codes. It would have to be a separate key so as to not interfere
with existing plugins that depend on no404.nasl.

Modify the whisker code to not bark about 403 requests if this new
no404.nasl key is in the kb.

Does this sound like a reasonable change?

P.S. I'm looking at the nessus 2.0.8 code.

Thanks
Erik

Re: Whisker Research [ In reply to ]

deraison at nessus

Nov 3, 2003, 7:46 PM

Post #2 of 5 (744 views)

Permalink

On Thu, Oct 30, 2003 at 10:50:05AM -0700, Erik Stephens wrote:
> Make no404.nasl store something in the kb when it gets 403 return
> codes. It would have to be a separate key so as to not interfere
> with existing plugins that depend on no404.nasl.

This would be good. Actually webmirror.nasl stores
www/<port>/password_protected if it only get 403 error codes. I found
some web servers which would wait 5 seconds before giving you a reply
when a page is forbidden, and I'm wondering if it would make sense to
disable ALL web checks when we meet such a server.

-- Renaud

Re: Whisker Research [ In reply to ]

erik at edgeos

Nov 10, 2003, 12:33 PM

Post #3 of 5 (742 views)

Permalink

On Mon, 3 Nov 2003, Renaud Deraison wrote:

> On Thu, Oct 30, 2003 at 10:50:05AM -0700, Erik Stephens wrote:
> > Make no404.nasl store something in the kb when it gets 403 return
> > codes. It would have to be a separate key so as to not interfere
> > with existing plugins that depend on no404.nasl.
>
> This would be good. Actually webmirror.nasl stores
> www/<port>/password_protected if it only get 403 error codes. I found
> some web servers which would wait 5 seconds before giving you a reply
> when a page is forbidden, and I'm wondering if it would make sense to
> disable ALL web checks when we meet such a server.

While getting my patches tested I noticed a CVS log message indicating
that whisker will be removed in favor of nikto only. This sounds like
a good idea. How can I tell what version of nessus those changes will
be released under? Thanks.

Best regards,
Erik Stephens www.edgeos.com
Managed Vulnerability Assessment Services

Re: Whisker Research [ In reply to ]

deraison at nessus

Nov 10, 2003, 12:37 PM

Post #4 of 5 (743 views)

Permalink

On Mon, Nov 10, 2003 at 12:33:36PM -0700, Erik Stephens wrote:
> > This would be good. Actually webmirror.nasl stores
> > www/<port>/password_protected if it only get 403 error codes. I found
> > some web servers which would wait 5 seconds before giving you a reply
> > when a page is forbidden, and I'm wondering if it would make sense to
> > disable ALL web checks when we meet such a server.
>
> While getting my patches tested I noticed a CVS log message indicating
> that whisker will be removed in favor of nikto only. This sounds like
> a good idea. How can I tell what version of nessus those changes will
> be released under? Thanks.

In the new releases. So 2.0.10 and 2.1.0 when they are out.

-- Renaud

Re: Whisker Research [ In reply to ]

mikhail at nessus

Nov 11, 2003, 2:59 PM

Post #5 of 5 (742 views)

Permalink

Erik Stephens <erik@edgeos.com> writes:

> We are noticing that the whisker plugin (ID=10845) has been the main
> source of false positive CGI abuses.

I solved the problem simply: as Whisker is supposed to be obsolete, I
removed the plugin from the CVS tree.