Correct, and a good point. I probably should have been more precise in
expressing my opinion.

The purpose/method of any scanner is clearly to send signals and listen to
the responses to these stimuli to gain information about what is/is not
running, etc.

To answer your question however, there are very few "normal" programs that
would send "43ffffff0000000004120" as opposed to "GET / HTTP/1.0". By
determining that Bagle responds specifically to the former by "shutting
down" and then intentionally sending that when the port is found open is OK
as a diagnostic tool, since most other things listening to the same thing
would not shut down. The difference is when the intent becomes to try to fix
the problem.

The problem I have is that of the worst case situation. If a new version of
Bagle (or something else) were written to trigger damage on receipt of
"43ffffff0000000004120", then nessus would quickly become a part of the
problem. Not something I would like to see on the news ("Security scanner
causes more damage in latest virus outbreak."). It would be
difficult/impossible to explain to the public that "43ffffff0000000004120"
is not very different from "GET / HTTP/1.0".

I think this particular point turns (for me anyway) on the intent. It is
different to send "GET / HTTP/1.0" and determine what version of a server is
present by the response because it is normal stimuli for a legitimate
service. No one would fault nessus if a virus writer took advantage of this
and wrote something that listened on TCP 80 and triggered it's damage on
receipt of a normal GET request.

So there is the perception problem in a worst case scenario.

There is also the fact that anti-virus tools already exist to not only stop
but fully remove the bug. If nessus is used as part of a suite of tools in a
security framework, why should it try to (intentionally) overlap with other
tools? Should it start sending alerts as an IDS? Try to tear down
connections when it see's bad traffic like "active response"? Be designed to
also be a firewall on a multi-homed box at the perimeter?

I simply think it is a better use of this tool to focus it on scanning, just
as snort is focused on IDS, CheckPoint/iptables/PIX are focused on being
firewalls.

Consider that you could clearly use snort logs to determine that host X is
infected with a virus/backdoor. Should part of snort be to send
"43ffffff0000000004120" when it thinks it "hears" Bagle? At least in this
case, it could be part of flex response. But I still do not think I would
enable it as long as I had anti-virus tools at my disposal.

Obviously, an anti-virus tool could be "tricked" into triggering the payload
of a virus by a clever virus writer. Similarly a determined intruder could
create a way to trick an active-response IDS into causing damage to the
victim. But in these cases, the security team (should have) made a conscious
decision to weigh these risks when using the tools. By making nessus do this
(especially as part of default scanning) it complicates the work of the good
guys. They now have to understand and weigh for themselves the risks of each
plugin (yes, in a perfect world, they would be doing this anyway). But most
administrators will believe that nessus will "only" scan and not view it the
same as turning on snort's flex-response. (for example).
Obviously there will always be a grey area that blurs the edges of what each
tool is/does.

I simply think that in this case, the potential for danger is greater than
the potential gain.

Jim




> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Renaud Deraison
> Sent: Thursday, January 22, 2004 11:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Bagle remover + Nessus 2.2
>
>
> On Thu, Jan 22, 2004 at 10:30:19PM -0500, Jim Hendrick wrote:
> > I personally would voice my opinion against any plugin that
> intentionally
> > sends *ANY* signal to a known virus/backdoor.
>
> The very definition of a scanner is to send signal to the remote
> services. How is sending "43ffffff0000000004120" more dangerous than
> sending "GET / HTTP/1.0" ? If a "blackhat" infected the
> remote host and
> decided to do something bad with it, he could wait for any of
> the Nessus
> probe to come in.
>
>
>
>                               -- Renaud
>
> _______________________________________________
> Nessus mailing list
> [EMAIL PROTECTED]
> http://mail.nessus.org/mailman/listinfo/nessus
>

_______________________________________________
Nessus mailing list
[EMAIL PROTECTED]
http://mail.nessus.org/mailman/listinfo/nessus

Reply via email to