Slashdot Mirror
Multi-vendor Game Server (GameSpy) DDoS Attack
w4rl5ck writes "PivX has this security advisory about DDoS attacks using a single modem line and some game servers (i.e. Counter Strike, QuakeX, Battlefield 1942 - in short, those supporting GameSpy). Works via spoofed udp packages querying the server stats, and because udp is connectionless, the server simply answers - to the spoofed address, of course. Funny thing, isn't it? (originally found on heise.de)"
For coming up with a rather ingenious DDOS attack style. Mind you I wonder how many gamers on those servers were complaining about ping times when that was happening.
Way to go GameSpy, yet another ounce of proof of a useless service for idjits.
All in a days work.
*SNIFF* "God I love the smell of napalm^H^H^H^H^H^H severs burning in the morning"
Ignore the "p2p is theft" trolls, they're just uninformed
.. it wouldn't be hard to put in some sort of verification to ensure the packets are getting to an appropriate destination. Witness NFS.
Trolling is a art,
I always knew that the 'D' in D-Day stood for DDoS.
Perhaps someone familiar with the Gnutella protocol can say whether this has been fixed yet.
Comment removed based on user account deletion
Including a posting to bugtraq. The original advisory is on my website. It's dated 13th March 2002.
Assorted stuff I do sometimes: Lemuria.org
Part of the problem is all the totally clueless ISPs which don't do proper egress filtering. That is, they don't filter out outgoing packets with falsified sender addresses.
They've had years to do that, and still don't.
This is the same except the pizza restaurants are the games servers (there's tens of thousands worldwide), and the address you give is any port on any machine worldwide. And it's particularly nasty because UDP packets don't throttle back, so all the bandwidth to that machine gets soaked up by this attack, and the machine spends most of its time just throwing away packets it can't understand.
If someone has your IP address, you are screwed; whatever game YOU are playing.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"If you have followed DoS attacks over the past few years, you will have noticed that the big trends is the decline of UDP based attacks. This is not because attacks like Pepsi and Smurf aren't still out there, it is because ISPs are limiting their use by filtering out spoofed UDP packets on their routers. Comcast, Verizon, AT&T, etc. all have routers that check the IPs of all outgoing UDP packets and replace the spoofed source IP with the true source IP (by checking which MAC address and port on the switch the packets are coming from.
Consequently, these attacks are far less likely to occur because most people's ISPs "fix" their UDP packets to prevent against attacks that work this way. This doesn't mean there isn't a problem. Not every ISP implements it, and it only takes one person to launch a large scale attack. Plus, gamespy will probably be patched to fix this problem.
__________________________________________
Take comfort in your ignorance.
Grandmaster Plague
You could do this sort of reflection attack with just about any server using the SYN/SYNACK method, but this one is nasty because of the huge difference in size between the initial forged packet and resulting response. Reflection attack (Yes, that grc "end of the Internet" .com again. :^)
One line blog. I hear that they're called Twitters now.
It would be possible to send the UDP packets at the game server with the source IP addresses spoofed to be the IP address of the game server itself. Nasty.
This would probably be self limiting since as the server slows down it would reduce the amount of packets it sends to itself, but it would probably be pretty nasty to the server as it sends and recieves flood loads of crap.
Hope a patch comes out soon...
-- Mike
Lots of server protocols prevent attacks by requesting a cookie before they do anything difficult or resource-consuming. Besides security, that's useful for basic reliability - it makes sure the IP routes are all working, the client can reach the server, the server's working, and the server can reach the client, before either side does any real work. Most exceptions to this are simple protocols like DNS that don't require any state or much work and would do more work building the connection than sending the real data, and things like NFS which have some reason for the client to trust the server's availability before sending big packets and which make sure that retries with the same data are ok.
Some of the crypto protocols, such as Photuris, do a cookie handshake first, because the first "real" step of the protocol comsumes lots of server CPU, and they'd be vulnerable to denial-of-service attacks otherwise. In this case, the attack is a forged-request attack on an unsuspecting client, but the server is still the only one that can provide any protection. Either way, the client firsts requests a cookie from the server, and the requests for real work need to include the cookie, or the cookie modified in a way that clearly indicates it was received.
A variation on cookies is to make the client perform non-trivial amounts of work using the cookie, which the server can verify quickly - this lets the server limit the rate of requests, and means an successful attacker needs lots more resources than the server. Hashcash is the canonical one - the client has to use brute-force search to find a string containing the cookie that has a hash value starting with a specified N bits, and the server can verify the hash quickly. This defense can be made stronger by including the sender's identification and a timestamp in the cookie string, making it harder to replay. While it's not possible to tune hashcash CPU consumption precisely (since different machines are different speeds, and the attacker may have a Beowulf cluster of Crays or a bunch of zombies to do calculations), the server can adjust the rate of requests by adjusting the hash length as needed. In addition to fullscale cookie-based hashcash, it's sometimes adequate to do a simple userid-and-timestamp version, or userid-and-counter, so the attacker has to do some work, e.g. burn a second of CPU time for every 2KB of response for a modem user, or 10KB for an online user, to prevent swamping.
In this environment, though, anything that requires client upgrades won't fly; you're stuck with upgrades to servers (tough enough) and handshakes that use the existing user interface.
Modifying the server to limit the number of responses per second for a given client (or of big responses) is probably a good start - it doesn't solve all the problems, and the attacker may be able to forge a stream of requests that prevents the victim from doing legitimate queries, but it protects the network connections. Another approach would be to do something password-like - the user queries for a password, or chooses a password, and has to use it to get any big queries, or more than N big queries.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks