Re: Naptha - New DoS

[Ryan Permeh <ryan () EEYE COM>]

it doesn't have to be like that, that just happens to be one way to trigger
the problem.

when we first saw the problem a while back, we came up with this exploit:

attacker: block all packets containing tcp FIN flag(in and out) and RST.
connect to victim on a port that slow closes and doesn't force RST the
connection(ie: apache in daemon mode),  close connection, repeat.

This doesn't obscure your source ip for the dos, so don't attack people with
this technique.

the supposed spoof/sniff attack that bindview mentions is simply to obscure
a local stack(and give the attacker a little more leeway).  a simple phantom
stack could do this quite easily, since it really doesn't have to deal wiht
much more than a simple tcp state machine(only tcp start handshake, and
possibly enough to make a request, and an arp responder), and a few calls to
libnet and libpcap.  The phantom stack still requires the spoofed ip be on a
locally sniffable segment, so that responses can be read from the wire.  A
compentent admin should be able to use arp tools to track a phantom stack
down to a specific segment and use a bat to stop the attack.

Now for the question that i never understood: Naptha seems to "exploit" a
problem in the TCP RFC.  microsoft often breaks this rfc by ususally using
RST to close a connection, and dropping the connection from it's internal
state table.  Why is there a fin state wait of so long on most moder os's?
perhaps i'm overlooking something, but in what scenario is there going to be
data on a socket in FIN1 state for any perceptable time anymore?

Signed,
Ryan
eEye Digital Security Team
http://www.eEye.com

----- Original Message -----
From: "Damian Menscher" <menscher () UIUC EDU>
To: <VULN-DEV () SECURITYFOCUS COM>
Sent: Monday, December 11, 2000 9:27 PM
Subject: Re: Naptha - New DoS


> On Mon, 11 Dec 2000, AV wrote:
> > Mon, 11 Dec 2000 09:47:54 +0100 Stephane Aubert wrote:
> >
> > > Overview of the attack
> > > ======================
> > >
> > > This attack can be launched from several sources (such as ddos
> > > infected computers or else) and use a very specific RESET server.
> >
> > [snip]
> >
> > > New idea:
> > > ---------
> > >
> > > In order to consume resources on the victim ONLY and deny it, we use a
> > > reset server to close the connection on the attacker side.
> >
> > Possibly, it's a good solution to use something similar to the traffic
> > shaper, which should permit no more than MAX_CONN_PER_IP open
> > connections from one given IP. I suppose, now it is a "must have"
> > feature of every firewall. The only disadvantage I can suggest: the
> > attacker may use more than one computer to launch the exploit, but
> > finding an additional computer is much harder than a number of loop
> > iterations.
>
> You don't seem to understand exactly how the attack works.  *The
> attacking IP does not exist.*  If the attacker has a lan that has 255
> IPs, but only 100 are used, then they use one machine to spoof the
> remaining 155 IPs, and another to resolve those connections.  Still just
> two machines running the attack, but will get past your traffic shaper
> if it just looks for multiple connections from a single IP.
>
> Damian Menscher
> --
> --==## Grad. student & Sys. Admin. @ U. Illinois at Urbana-Champaign
##==--
> --==## <menscher () uiuc edu> www.uiuc.edu/~menscher/ Ofc:(217)333-0038
##==--
> --==## Physics Dept, 1110 W Green, Urbana IL 61801 Fax:(217)333-9819
##==--
>