Forwarded from: security curmudgeon <jerichoattrition.org>

> http://212.100.234.54/content/55/28851.html
>
> By Tim Mullen
> Security Focus Online
> Posted: 14/01/2003

> To refresh, I believe you should have the right to neutralize a worm
> process running on someone else's infected system, if it's
> relentlessly attacking your network. I've even written code to
> demonstrate the process. Though the initial news coverage of the
> concept was grossly inaccurate in conveying my ideas, it has stirred
> up a constructive dialog.

> It has been the "security experts" who have grouped as the
> opposition, some even with a level of condescension. For instance,
> Eugene Schultz

> I think the main reason for the knee-jerk criticism from the likes
> of Schultz is that they work largely in a theoretical rose-colored
> world of security, where all problems are solved after a cup of
> coffee and a bit of pontification. Those who actually work in the
> operational end

Heed your own insults Tim. Your proposal falls in the category of
theoretical rose-colored solutions. Hopefully you enjoyed your coffee
as you pontificated.

There are several issues that you do not clearly address in such a way
to sell this idea. Further, by bringing up the details, you will open
yourself up to further criticism and further validate the criticism on
the table already.

Who defines "relentless" attacks? Is one worm spamming your web server
with 6 hits every 30 minutes as it tries to spread "relentless"? Is it
really threatening your machine or stealing your bandwidth? What if is
the same 6 hits every 5 minutes? Or even every minute? Is that really
a "relentless attack" or is that an annoyance? Is your answer the same
as everyone elses?

Who authenticates these attacks? Are your web logs grounds for you to
engage in what is normally considered felony level activity and title
18 violations? Are you sure you are reading those web logs right? Have
you considered some possible scenarios that might challenge your ideas
on strikeback?

  What if I forge some logs showing tim-mullen.com being worm infected
  and attacking my systems? Now I break into your system and "kill your
  malicious processes" *at my discretion*. Well, the worm utilizes syslog
  in one place, so let me kill syslogd. The worm uses this other process,
  you dont need that "kswapd" anyway.

  What if I hack c4i.org and then do a few lynx calls that mimick a worm's
  signature. Now you are mad and you want to break into c4i.org and stop
  the activity. Court battle ensues.. you have logs showing the attack,
  William Knowles has system logs showing no such infection, but does
  have the logs of you hacking into his system. Who is in the wrong here?
  Who is the court going to believe when they review all the logs?

  Let's consider a large business I run, where I am typically very good
  at maintaining a secure network. One day I install MS Patch #982349823
  and go home. That night a 0day worm compromises my system and tries to
  spread, attacking your system. Am I really liable at this point? Let's
  pretend that during your frenzied strikeback session you kill the worm
  and also typo the process number. When my proprietary database shuts
  down uncleanly and corrupts the last 100 customer transactions and
  further corrupts a different database. Who is liable here?

These are three examples off the top of my head that show some serious
flaws in the idea of strikeback technology. You are definitely not the
first to bring this idea up, and you are certainly not the first to
consider all the scenarios and ramifications.

If you find yourself asking what else can be done to stop these
problems, one answer that comes to mind is simple. ISP's need to be
more reactive to complaints about abuse on their network. Their
customers already sign an agreement stating they will follow an
Acceptable Use Policy. Every AUP I have seen covers malicious activity
like you describe, and puts the liability on them. If your system
attacks mine, be it from automated worm or not, and I report that
activity to your ISP.. they need to kill your conneection until the
problem is solved. If they read the logs I sent, they can then make
the determination if it is a serious problem, contact you, or monitor
your traffic to find their own verification of the activity. Once they
find it, they pull your plug and problem is solved temporarily. While
this system is not flawless, it is certainly more feasible and
responsible than any strikeback proposal.

-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomoattrition.org with 'unsubscribe isn'
in the BODY of the mail.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]