[iwar] Historical posting


From: Fred Cohen
From: fc@all.net
To: iwar@onelist.com

Mon, Jan 1, 1999


fc  Mon Jan 1, 1999
Received: (from fc@localhost) by all.net (8.9.3/8.7.3) id FAA15269 for iwar@onelist.com; Tue, 18 Apr 2000 05:21:43 -0700
To: iwar@onelist.com
MIME-Version: 1.0
Mailing-List: list iwar@egroups.com; contact iwar-owner@egroups.com
Delivered-To: mailing list iwar@egroups.com
Precedence: bulk
List-Unsubscribe: 
Date: Mon, Jan 1, 1999
From: Fred Cohen 
Reply-To: iwar@egroups.com
Subject: [iwar] Historical posting

          

 The following security advisory is sent to the securiteam mailing
list, and can be found at the SecuriTeam web site:
http://www.securiteam.com

          The risks of counter-attack tactics
----------------------------------------------------------------------
----------
SUMMARY

Most IDS (Intrusion Detection System) applications let you choose an
action to be performed when someone tries to probe the host, or when a
possible attack is conducted.
The default action is usually to 'cloak' the host; completely block
all
incoming network traffic from the (possibly) offending station in
order to
avoid further attacks.

Below is an excellent explanation by  <mailto:mhw@w...
Michael H.
Warfield on why any counter-attack/counter-probe reaction system is
prone
to backfire and be turned against the owner.

DETAILS

When a probed host responds to the probes by querying the prober back
(the
host from which a probe is allegedly coming from), you are not helping
your self but rather you are tipping the intruder off that you've
spotted
him.  Even something as simple as a ping can do this. You've also told
him
that he hit pay dirt in some way since you've obviously got something
more
sophisticated than some Windows box there. He also could easily deduce
that you are running some sort of probe reactor that could be fun to
play
with.  If he's got a lot of throw down accounts, you could be in for a
lot
of unwanted attention.  You generally want the attacker to just go
away
and you could easily have the exact opposite effect of attracting his
attention.

A smart intruder could well have his system primed to feed back false
information.  Falsifying information returned by ident, finger,
netbios,
etc is a snap to do and stock tools already exist for doing it.
So trying to rely on any information you get back is useless anyway.
He
could possibly even return other attack attempts!  Just connecting to
the
ident port is likely to get you a "poison pill" back from an evil
ident
server.
Sendmail was busted this way once, years ago.  Are you sure all those
buffers are protected from overflows?  What happens if he gives you a
user-id that's the first 10 chapters from "War and Peace" and gives
you
the rest of it for the host name?  Like to see your name up in lights
on
BugTraq or Attrition?

Once the intruder spends a little time figuring out what your reactor
does, he can then set up fake attacks or spoofed attacks to see what
he
can trick you system into counter attacking.

One trick got pulled on a security expert several years ago.  He had
his
system armed to respond to any attempts to telnet to his system.
If you telneted to that system, he responded with an obnoxious banner
accusing you of attempting to hack his system.  He automatically
E-Mail
complaints to you, your admin (root & postmaster - maybe abuse too),
the
admin for your parent domain and the POCs (Point Of Contact) for your
domain and your network address.  Somebody out in netland got wind of
this
and decided to have a little fun.  They created a web page with lots
of
enticing erotica, tempting meta-tags, and other bait.  They added
several
URLs that resulted in connection attempts to port 23 on the chump's
system
(I believe they used "IMG SRC=" tags and specified a telnet URL or
explicitly called port 80).  Then they just sat back and waited for
the
search engines to do their work.  A few weeks later, the dude's system
was
getting flooded with telnet attempts and he was spewing E-Mail out
like
the big bang all over again.  Needless to say, the admins of the
systems
and domains that received this E-Mail were not amused and had no clue

We've seen and discussed ideas for setting up similar web pages that
would
simulate port scans and other tricks.  This was under the premise of
"what
would happen if someone did this to us" sort of thing.
It doesn't create too much havoc if all you are doing is reconfiguring
a
firewall.  You cut off the dude doing the browsing - but so what?
That's not worth the effort of setting up a fake page for.  Expiring
filter rules even cleans that up.  If you "react" to the probe by
launching a counter probe yourself, what are you likely to be doing?
How
are they likely to react?  What if the innocent bystanders also have
security alarms?  What if they contact law enforcement?

At a recent security conference (ISS Connect 2000) we had a BOF on
counter
attacks and reaction systems.  One issue that's raised is that of
legal
liability.  What if someone tricks you into probing another system
(say a
military system) and that looks like YOU are trying to break into THAT
system?  Do you want to be in the position of explaining to your
corporate
lawyers the technical details about how you were tricked into doing
this?
What if they've been broken into recently and all they see in their
logs
are your probe attempts?

Even false accusations that someone has been attacking you can get you
into legal hot water such as liable and defamation.  What if you got
someone fired based on the information probed and then they come back
and
sue you?

Next fun game is the recursive pong games you can light up.  What if
the
other system is behind a similar firewall that also has a reverse
probe
that responds to perceived intrusion attempts?  It used to be a cute
trick
to "finger" the other system when someone attempted to probe you.
Problem was that a finger attempt could be misinterpreted as a probe
attempt.  Several instances occurred where systems got in a "food
fight"
throwing finger requests at each other in response to the finger
requests.
A couple of self-inflicted denial of service attacks ended that trick.

Morals of this story:

- Don't tip him off that you've spotting him.

- Don't inform him that you have sophisticated detectors.

- Don't rely on information that he controls.

- Don't open yourself up to other indeterminate exploits and attacks.

- Don't open yourself up to being abused to attack others.

- Don't open yourself up to legal liabilities.

- Don't open yourself up to potential denial of service attacks,
self-inflicted or otherwise.

- Whatever you think you might gain by doing this is not worth the
risk.


ADDITIONAL INFORMATION

The above argument was provided by  <mailto:mhw@w... Michael
H.
Warfield.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and
body to: list-unsubscribe@s...
In order to subscribe to the mailing list, simply forward this email
to: list-subscribe@s...
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty
of any kind.
In no event shall we be liable for any damages whatsoever including
direct, indirect, incidental, consequential, loss of business profits
or special damages.

Det. Robert W. Miller
Colorado Internet Crimes Against
Children Task Force
Pueblo High Tech. Crime Unit
Pueblo County Sheriff's Office
909 Court St.
Pueblo, CO. 81003
Tel (719)583-4736
FAX (719)583-4732
mailto:snooker@i...
mailto:cicactf@i...
http://www.co.pueblo.co.us/sheriff/
PGP key available at: http://pgpkeys.mit.edu:11371/
search on snooker@i...