It’s (like Lanz said) a response from the master server with a list of server IPs. Normally, the server browser sends a packet to masterserver:27950 with a command like '\xff\xff\xff\xffgetservers 83 empty full demo
’ (in the case of ET), to which the master server responds with a stream of packets that look like '\xff\xff\xff\xffgetserversResponse\AAAABB\AAAABB\AAAABB…\EOT" (where AAAA is four bytes making up the server IP address, BB is two bytes making up the server port, and there are 112 servers total.)
The problem is that, unlike the majority of the Quake-related connectionless commands, getservers doesn’t require you to respond to a challenge before it gives you the server list. This is especially unfortunate in this case, since the getservers command returns a fairly large amount of data.
To detail on the challenge I just mentioned–several of the connectionless commands from Quake-engine games require you to answer a challenge before you get to do anything interesting in order to verify that you are really the person who is sending the request. For example, when you connect to an ET server, the game sends ‘getchallenge’ (and displays ‘Awaiting challenge…’ to the user); then, the server sends back ‘challengeResponse <random number>’ to the client; and then, the client sends back that random number to the server in the connect request. If the random number that the client sends back doesn’t match what the server gave out, the connection is rejected as invalid (so it’s very difficult for someone malicious to spoof a connection to the server.)
Here’s a brief, simplified illustration (italicized text indicates data that’s actually sent compressed):
[quote="
is difficult to read"]
<pre>[b]Client [/b] [b]Server[/b] [b]Client prints[/b]
getchallenge "Awaiting challenge..."
challengeResponse -1384463566
connect [i]\challenge\-1384463566\...[/i] "Awaiting connection..."
connectResponse "Awaiting gamestate..."
[i][gamestate data][/i]</pre>(etc...)
[/quote]
To demonstrate the problem, I can send the getservers command to the Quake 3 master server with a forged source IP (the IP of another server I administer), e.g.:
[quote="
is difficult to read"]
victim.host:6667 > master.quake3arena.com:27950 (udp): "\xff\xff\xff\xffgetServers 68 empty full demo
"
[/quote]
The result is similar to what Kamel posted:
[quote="
is difficult to read"]
12:08:51.728067 monster.idsoftware.com.27950 > victim.host.6667: udp 810
12:08:51.732550 monster.idsoftware.com.27950 > victim.host.6667: udp 810
12:08:51.737068 monster.idsoftware.com.27950 > victim.host.6667: udp 810
12:08:51.741570 monster.idsoftware.com.27950 > victim.host.6667: udp 810
12:08:51.746083 monster.idsoftware.com.27950 > victim.host.6667: udp 810
(etc.)
[/quote]
The high packet rate in itself isn't indicative of a DOS attack--a normal response to the request will consist of about 21 such packets as rapidly as shown; however, the fact that the packets kept going long enough for you to realize trouble was afoot (along with the destination port of 6667) IS a good indication.
So, to summarize, it is an amplification attack (although not via the game server itself, but rather, the master server), and letting Id know about it (if you haven't already) would be a good idea, as it is/was wasting their bandwidth.
Why yes, I [i]am[/i] having a slow morning!
...why do you ask?
