Date: Mon, 4 Dec 2000 17:25:07 -0800 From: Alfred Perlstein To: security@FreeBSD.ORG Subject: NAPTHA/RAZOR response. Message-ID: <20001204172505.D8051@fw.wintelcom.net> Ok, I can't believe what a bunch of hosers these RAZOR/bindview guys are, thier "advisory" is nothing new, there was a news article about 3 years ago talking about this problem, all that RAZOR seems to have done is find a pretty lame and broken way of spoofing the source of the attack which doesn't really work. (it's trivial to find the source of the attack) Way to go being a bunch of attention grabbing lemurs guys, congrats on the ZDnet article! So on with my own response 'advisory', enjoy: fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear ________ _______ ____________. .______ __________ _______ / | | .' \| | \ fear**/ | | : \ | \**fear / | | _______| | | \ / | | > / | \ .' | | : / | \ | | | ____| / | | | : | | | . / ______) | | | | | | | < | | | | | | | \ | | | | | | | | |\ \ | | | | |______:___ | \ \ ______) | f| | | ) | \ \ | |ear | Perlstein | /. | \ \ | | (______)_______)_______________/ |______| (______)_______|__________/ fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear [ Dayam where's the sploitz at? ] [ Sploit...... NAPTHA 1.2 ] [ Dumbasses responsible...... RAZOR ] [ Analysis by..... Alfred Perlstein ] _________.. . . | : Summary ' RAZOR noticed that when you create a lot of connections to a service you effectively cause the remote side to fork bomb and/or consume resources waiting for the connections to time out. By slowly trickling expected ACKs back to the application/server one can also keep a lot of resources tied down in both the application and kernel levels. RAZOR wasn't the first bunch of tools to notice this effect, amazingly this effect is seen by a lot of first year computer science students when they take their first network programming class. What RAZOR doesn't seem to clue in on, or just pretends that it's not a big deal is that this attack requires local ethernet access to be spoofed . otherwise unless the victim OS has easy to predict TCP sequence numbers.. ...the attacker must reveal the source of the attack (his IP). : | .........____| _________.. . . | : Exploit (abstract) ' When NAPTHA is deployed remotely one can simply use tcpdump to figure the source location of the DoS. When NAPTHA is deployed locally using ARP tricks to hide one's IP one can simply log onto local switches and view the ARP cache to discover the source. After finding the source of the attack you'll need: 1) a crowbar 2) some duct tape 3) a gerbil Use 1 (the crowbar) to break the offender's legs and arms, then apply 2 (the duct tape) to offender, we'll leave the use of item 3 (the gerbil) to your imagination, I'm sure you'll figure it out. : | .........____| _________.. . . | : Workaround ' Drop idle connections faster and deal with resource shortages gracefully. (duh!) : | .........____| _________.. . . | : Shoutouts to: ' halah (u rul3 m3 b4by), j4mes, ps, pm (just kidding, n0 gr33t 4u), jba (el8warez 4 u) and jkh (journey rulez) Big :P go to: RAZOR (one word: lame) CERT (why'd you guys release this junk?) . SIIG (th3s3 h0s3rz package different chipsets in the same boxes) : billf@efnet (d00d, where's my O: ?) | This advisory crafted with vim, damn i miss TheDraw :/ .........____| *narf* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message