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.
Good to see that an actual error was found with the program - It might make developers think twice before using their bloated propriatary, closed, middleware that is all but designed to lock out other browsers like all seeing eye.
Perhaps someone familiar with the Gnutella protocol can say whether this has been fixed yet.
This appears to be a huge vulnerability in a lot of programs used by a lot of people (including a lot of us) that could allow a couple dozed (or less) script kiddies to take down a lot of game servers. That 1:393 response ratio is awful. Some kid with DSL could take down, what, 20 servers at the same time? What chance is there that EA will release a patch some time soon? They had been notified like 2 months ago, and haven't even responded yet.
I always knew GameSpy was a crappy product, but this just brings it to a whole new level.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
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
And if those packets happen to slam into your Linksys BEFSR41 router, it will freeze up, crash, and flop around like a half-dead fish.
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!"There are a hundred other programs that do the same thing as Gamespy, it's not their fault. They work around the protocols that the game uses.
This is something that needs to be addressed by Game Developers (Valve, ID, etc.)
There is a great PDF (HTML version) of a research paper by Jeff Kato and Ryan Zojonc on all the issues of massive multiplayer gaming systems and leagues and why/when/what security breaches have occured and could occur in the future.
Why do people attack games?
- To get private info about others
- They pirate a game and want to play it online
- To get credit card numbers
- To cheat
- To delete others' characters
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
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 kind of wonder why programmers wouldn't put some sort of UDP reply limitation in the query system of all these games.
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.
i'm glad to see they had enough responsibility to put a couple "errors" in the proof-of-concept code so script kiddies dont just compile and have fun. i.e. #define DSTPORT 230
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
Exactly! Check the source address, see if it matches what was assigned to the port. If not, shut the guy down for 10 minutes. This would prevent almost all DoS attacks if every ISP did it.
Of course, there must be a reason they don't.. I'm assuming it's just too CPU intensive to do something like that for every packet. Perhaps every 100th packet? People who are DoSing are likely to be sending out thousands of these packets anyways, so you'd probably still catch them.
Though, to be fair, it'd probably be easier for Taco if HTTP *were* stateful, and easier for the Gamespot people if they were using a stateful protocol.
WTF do they do that, anyway? I mean, UDP makes plenty of sense for the in-game engine in Quake or something, but has little point for just transmitting server lists.
If they're trying to do traffic reduction, I'd think they'd be better off implementing advanced queries, so that the *server* can return only the list of servers you're interested in, instead of the client having to do filtering on an enormous dataset all the time. Most people have some pretty easy-to-fit contraints (no more than a certain ping time, usually same continent, usually a specific game type...)
May we never see th
ISPs wouldn't even be that specific. Since many of these DDoS attacks depend upon tricking another machine into sending packets to the real target of the attack, it would help a great deal if ISPs at least made sure outgoing packets matched their own subnets. How intensive could it be to check the first 2 octets and drop the packet if they don't match a class B subnet the ISP uses?
Not sure how this wouild work, but require sort of a handshake to get data. I.e. the client sends a request to talk, the server replies with a auth token (some integer), then the client sends the auth token + query. auth tokens would be attached to an ip so it could be chached for faster queries, but required that a connection be authed to get data. Then the server only sends data on about a 1:1 ratio is the client doesn't send a token. Commands w/o a token would be ignored.
All of this is done (better, IMHO) using ingame server finding/selection. Gamespy is for games what AOL is for the 'internet'.
"During times of universal deceit, telling the truth becomes a revolutionary act." - George Orwell, 1984
UDP Message: GIVE ME STATS!
UDP Reply: Challenge #HASHOFCURRENTTIME
UDP Message: VERIFY #HASHOFCURRENTTIME
UDP Reply: DATA
Problem Solved(TM)
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
This vunerability has nothing to do with GameSpy, if it did, we'd be poking a knife into the All Seeing Eye etc as well. GameSpy/ASE simply provide a legitimate mechanism to query servers, using protocols that have become defacto among games and their designers. It's like blaming knife rack makers when people use the knifes to kill.
/. would be above something petty like throwing company names into a topic title, especially when the given company is a big proponent of the use of an open standard, rather than locking out users of other programs.
The protocol normally used is UDP. However, since it's connectionless this protocol is open to abuse by malicious client machines. All that's involved is a standard spoof connection request, which the servers will quickly discard after a timeout. The average game server has connection management that allows for dozens of clients, and since there are tens of thousands of game servers I doubt we'll be seeing a signifigant abuse problem using this mechanism.
I would have thought