Vulnerability Development mailing list archives
Re: Naptha - New DoS
From: Ryan Permeh <ryan () EEYE COM>
Date: Tue, 12 Dec 2000 22:44:03 -0800
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
##==--
Current thread:
- Re: Naptha - New DoS, (continued)
- Re: Naptha - New DoS Jose Nazario (Dec 09)
- Re: Naptha - New DoS Lincoln Yeoh (Dec 09)
- Re: Naptha - New DoS Ron DuFresne (Dec 09)
- Message not available
- Re: Naptha - New DoS Lincoln Yeoh (Dec 09)
- Re: Naptha - New DoS Jonas Thambert (Dec 09)
- Re: Naptha - New DoS Simple Nomad (Dec 11)
- Re: Naptha - New DoS Dug Song (Dec 11)
- Re: Naptha - New DoS Stephane Aubert (Dec 12)
- Re: Naptha - New DoS AV (Dec 12)
- Re: Naptha - New DoS Damian Menscher (Dec 13)
- Re: Naptha - New DoS Ryan Permeh (Dec 15)
- Re: Naptha - New DoS Dug Song (Dec 15)
- Re: Naptha - New DoS Simple Nomad (Dec 11)