RE: A question for the list...

["John McCracken" <john () mccrackenassociates com>]

You raise a very good point, Rob, and perhaps that is/was the instant case,
assuming their code only affected/disarmed the malware, this time. However,
I wonder if, from a reliability perspective, that would be the case in
future instances and for this reason, I would rather be notified if my
system(s) were infected rather than have unauthorized code alter my
system(s) by whomever deems it necessary, good intentions or not. It seems
to me this type of action, without adequate permission and acknowledgement
by end-users, is equally hazardous as a whole, could be difficult to
differentiate from malware, and might promote a network wide free-for-all
for whomever to run whatever code they believe is in their best interest to
mitigate damages.

While I can relate to and appreciate the hard and soft monetary losses we
all sustain due to malware that is part of a total cost of ownership, I
personally would rather have the freedom of consent and acknowledgement
prior to code executing on my system(s), which is why most of us harden our
production system(s). The fact that many do not, for whatever reason, and
become infected should not set a precedence of authority for unauthorized
access, which may be more the root of the issue than the motive of good
intent. Perhaps an answer resides within the question, whom should we
blindly trust to run code of their choice on our production systems? I
suspect most of us would have a difficult time listing but a few, if any at
all, which is why most of us independently test code on development systems
prior to rolling it out into production.

Thanks!
John McCracken

-----Original Message-----
From: Rob Shein [mailto:shoten () starpower net] 
Sent: Sunday, May 18, 2003 6:34 PM
To: 'Dan Hanson'; incidents () securityfocus com
Subject: RE: A question for the list...

What is being done with respect to Fizzer is rather different from "engaging
the attacker" or even scanning large sections of the internet to find
compromised hosts in pursuit of fixing them.  The method being used is
neither active nor aggressive, and here is the key difference.  I think the
likelihood of harming others is far less in this scenario, and I doubt that
there is even a potential legal issue either, for that matter.  As the virus
reaches out for an update from a known location, here there was the
opportunity to cause the virus to elegantly commit suicide; there is no way
that the code would accidentally be run on an uninfected machine except with
the direct participation of that machine's owner.

-----Original Message-----
From: Dan Hanson [mailto:dhanson () securityfocus com] 
Sent: Saturday, May 17, 2003 12:28 AM
To: incidents () securityfocus com
Subject: A question for the list...


As part of incident handling and response, most of us have had to respond to
virus infections that have affected networks and hosts. Reports are
circulating that members of the IRC operator community have distributed code
through the update mechanism of the Fizzer virus. The code reportedly
attempts to remove the virus from the host. The latest information seems to
indicate that the "update" code was removed until further testing can be
done and more discussion regarding the legalities of this are had.

At last year's Blackhat conference in Las Vegas, Tim Mullen presented what
turned out to be a very controversial proposal. Briefly, he questioned why
it would be inappropriate to strike back and disable (if not remove) a worm
from hosts that are clearly not being adequately managed.

The discussion, both in the session, and after, included those who felt that
this was simply vigilanteism that has no place in the current world, and
those who feel that there is a responsibility for someone to do something to
try to maintain, if not improve, the security situation for those connected
to the Internet.

http://online.securityfocus.com/columnists/98
http://www.blackhat.com/html/bh-usa-02/bh-usa-02-speakers.html#Timothy%20Mul
len
http://www.securityfocus.com/columnists/134

It seems to me that a group finally took it upon themselves to do exactly
what Tim was suggesting the community consider. But it appears that they
have done it without any consultation of the community in general, and if I
have read the reports correctly, with no authorization.

Here is a link for a report on News.com and it contains some opinions by
legal folk. http://news.com.com/2100-1002_3-1003894.html?tag=lh

A bunch of ideas for discussion pop-up to me... some of these may not be
totally on-topic for this forum, if you can tie something back into incident
response, I'll likely allow it through.

-What are the implications down the road?

-Are there concerns that organizations have with this trend? Legal?
Precedure?

-Is this any different than a similar activity that installs malicious code
on the target host?

-The approach that Tim advocated was significantly less intrusive than the
approach taken with the Fizzer virus, Tim's approach made no significant
changes on the targeted host, simply blocked the ability of Nimda to
replicate (if I remember correctly), and notify the owner that they have
been compromised and where to go to find help in removing the infection. The
approach taken to actually modify the system to remove Fizzer seems to go
significantly past that. Why was the reaction to Tim's advocacy of
discussion so hostile, and to date, I have seen no negative criticism of the
Fizzer removal.

-Is this a catalyst for a group (IETF?) of some kind to debate these issues
to find a resolution? I think that most people would agree that the
increasing risk that these distributed networks pose to every Internet
connected host is grave, and a better method is required to deal with them.
Are there other ideas that don't get us into "arms races" with malcode
writers.

-If this becomes standard practice, will this force the communication and
update channels underground/encrypted (the "arms race" that I mentioned)

-What are some of the strategies that organizations are implementing to
control their exposure to these communication channels?

-If a command can be given in a channel to "shut down" the network of hosts,
what is the view on the legality of doing this? If you had a host on your
network that was suddenly shut down by a well meaning (or not so well
meaning third party), what would your response be?

I am not advocating the validity of one side over another, I just find it
curious how similar the idea of Tim's, and the actual attempt to remove the
virus, are.

As an aside, I would like to keep the discussion on this civil. If posts
become to flamey to oneside or the other (i think both sides have valid
ends) they will likely be rejected.

D

----------------------------------------------------------------------------
*** Wireless LAN Policies for Security & Management - NEW White Paper ***
Just like wired networks, wireless LANs require network security policies 
that are enforced to protect WLANs from known vulnerabilities and threats. 
Learn to design, implement and enforce WLAN security policies to lockdown
enterprise WLANs.

To get your FREE white paper visit us at:    
http://www.securityfocus.com/AirDefense-incidents
----------------------------------------------------------------------------



----------------------------------------------------------------------------
*** Wireless LAN Policies for Security & Management - NEW White Paper ***
Just like wired networks, wireless LANs require network security policies 
that are enforced to protect WLANs from known vulnerabilities and threats. 
Learn to design, implement and enforce WLAN security policies to lockdown
enterprise WLANs.

To get your FREE white paper visit us at:    
http://www.securityfocus.com/AirDefense-incidents
----------------------------------------------------------------------------




----------------------------------------------------------------------------
*** Wireless LAN Policies for Security & Management - NEW White Paper ***
Just like wired networks, wireless LANs require network security policies
that are enforced to protect WLANs from known vulnerabilities and threats.
Learn to design, implement and enforce WLAN security policies to lockdown enterprise WLANs.

To get your FREE white paper visit us at:
http://www.securityfocus.com/AirDefense-incidents
----------------------------------------------------------------------------