Re: NetQuake Protocol problem resulting in smurf like effect.

[ambrose () MMAE ENGR UCF EDU (Ambrose Feinstein)]

> * Through the NQ (NetQuake) Protocol it is possible to send a spoofed
> connect request packet to several <i.e 400 or so> NetQuake Servers.  This
> then will result in a flood of attempted "Connect" requests from the
> servers' end to the target machine whether that target machine carries a
> copy of Quake or not. This may be perceived in a similar way to smurf
> attack, although I'm told it requires far less bandwidth "and can be done
> from even a 14.4"

last i checked it was hard to find 400 up.  (my list died cause the scripts
tried to run while i was over quota on the shell it was running from... i
now have a bunch of 0 byte files *sob*)  however, what you are suggesting
would work quite well as a smurf attack; one forged connect request, a 12
byte udp packet, would result in the server sending a 1032 byte udp packet
rougly once per second for net_messagetimeout seconds (default 300).

assuming a 28 byte udp header and no other framing, thats a bandwidth
multiplication of (28+1032)*300/(28+12) == 1060*300/40 = 7950.  not bad,
but with only around 200-300 public servers up last i looked, it would be
tough to fill one t1, as you only get 1k/sec from each server.  (you cant
get any more from one server with multiple connections; see below.)

> *  Apparently the fix is to send a DISCONNECT packet to each IP that tries
> sending UDP traffic in the attempt to initialize a NetQuake game.  This
> will cause the server "give up" trying to start a game, ending the flood.

actually, using the attack on yourself for the same set of servers would
work too; if a netquake server gets a connection from an ip already
connected, even on a different port, it drops both.

> I would just like to now note, as a matter of courtesy: I and to the best
> of my knowledge, no member of #LinuxOS discovered this bug, or wrote any
> exploit code for it. I and the overwhelming majority of #LinuxOS felt
> that it would be far better to alert the general community to "yet
> another" DoS attack.

the flow control (and network code in general) in quake is so poor that
this sort of thing does not surprise me.  i know about all sorts of mean
unpublished things you can do, and have used some of them, occasionally
legitimately.  (i used to use the above duplicate connect behavior plus
the query service to ban unwanted players from a server i administered,
without having to leave a client connected all the time (the qsmack
approach) or use a stdio pipe with the server console itself (not available
with a windows server anyway).  if the server host allocates local udp
ports in linear order, then with some educated guessing you can actually
hijack someones game connection, which is a neat trick :)  i consider
netquake to be (sadly, because it plays much better than qw or q2) a
declining community.

> I do not have the exploit or patch code, as I have said "AgentX"/"Playtex"
> on EFNet  (your friendly neighbourhood DoS supplier) was incredibly tight
> when it came to distributing any source code.  I would recommend asking
> him or one of his clique. I do however have tcpdump available from
> http://riva.gnu.net/nq-attack

silly.  forge one udp packet with contents "\x80\x0\x0\xc\x2QUAKE\x0\x3"
(no trailing null) to the server listen port, default 26000.  aside from
some raw ip code and looping over a list of servers (and locating a lot
of servers, not so easy these days) thats all it takes.

==zatz
(AF)