Re: Naptha - New DoS

[Simple Nomad <thegnome () NMRC ORG>]

I guess I should probably say something about all this. I can't speak to
why the advisory wasn't posted to BugTraq. The first advisory was a bit
lacking on technical detail and Elias wasn't going to let it through. A
second advisory was prepared that has more detail, but I don't know if
Elias has seen it yet, which would account for it not being posted.
Nonetheless, it is at
http://razor.bindview.com/publish/advisories/adv_NAPTHA.html.

Several questions have been raised about various OSes and how they are
impacted. When testing, we would use default installations. Now maybe this
might not make sense, but Bob Keyes (the NAPTHA developer) as well as the
rest of the team felt like this was a TCP/IP stack issue more than a
daemon or service issue. For example, a plain old default loading of Win2K
was not vulnerable to a NAPTHA attack regardless of TCP port targeted, but
NT was.

The question raised about why Red Hat 7 seems ok but Red Hat 6.x is
vulnerable could probably be accounted for by two things -- first, xinetd
is used by default on RH7 and not RH6, second, there are different kernels
and settings used between RH7 and RH6 which I feel have an impact between
the two platforms. When I tested RH6 and RH7 I attacked port 23 which ran
out of the default Internet daemon and port 111 which did not. On RH7 I
was never able to completely disable access to these ports, at least for
very long. RH6 fell over and required a reboot to recover.

Regarding Mixter's code, well, that isn't NAPTHA. Unfortunately Microsoft
said that NAPTHA was sending malformed packets, which it really isn't (or
if it is from Microsoft's perspective, that's not the trick). NAPTHA is
establishing a three-way handshake -- not just the regular attempt at a
connection flood which uses up resources on both the attacker's and
target's systems -- and handles the arp requests as well. By spoofing with
a non-existent address on the local net and making sure the arp requests
are handled as well, a *complete* three way handshake occurs (at least
complete in the way that everything gets crossed T's and dotted I's). Not
new in theory, but certainly new in implementation. And the implementation
is much more severe than previously theorized.

Regarding scut's comment that 3wahas already does this -- the answer to
that is not exactly. Forging just the TCP packets will work to a certain
extent, forging the generated arp requests as well will cause much more
effective and quicker resource depletion. Straight out of the compile,
NAPTHA works extremely well -- I found that 3wahas required a few arp
trick to really get the thing to work effectively. (BTW if you download
3wahas, add "libnet_" to all the call you get an error on and the code
should compile, it was written with an older version of libnet.) I know
Bob was unaware of 3wahas during NAPTHA development, and it was only after
the advisory came out did RAZOR become aware of it.

I hope this clears up a few things. Hopefully this coming week, we'll get
a bit more info about NAPTHA posted on the RAZOR web site, perhaps a FAQ
or something.

-         Simple Nomad          -     "No rest for the Wicca'd"     -
-      thegnome () nmrc org        -                                   -
-  thegnome () razor bindview com  - www.nmrc.org   razor.bindview.com -