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)"

Comments

Well You Have To Give Them Credit

[Lukano]

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.

Re:Well You Have To Give Them Credit

[quakeroatz]

Way to go GameSpy, yet another ounce of proof of a useless service for idjits.

Sorry? Yes, I'd be the first to bash Gamespy for their heavyhanded marketing approaches and Microsoftesque software pushing... but... they merely supply a tool that uses a service built into just about every FPS on the planet. This is an extremely useful service that's essential to find buddies, favourite maps and most importantly, the lowest pinging servers. Even "open" server browsers such as the All Seeing Eye use the same service as Gamespy3D/GamespyArcade and are equally susceptible to the same vulnerability.

Yes it's time to rethink client/server game querying, but not the time to bash M$, Gamespy or any other corporate scapegoat.

And to think Carmack didn't think about this years ago.... Shudder.

hehehe

[SuperDuG]

Kill your enemies. Kill those not on your team. Kill a server.

All in a days work.

*SNIFF* "God I love the smell of napalm^H^H^H^H^H^H severs burning in the morning"

Even if it is connectionless..

[grub]

.. it wouldn't be hard to put in some sort of verification to ensure the packets are getting to an appropriate destination. Witness NFS.

Re:Even if it is connectionless..

[Yokaze]

It would be and it is.

Connectionless is on the connection layer. This doesn't mean, that the application can't be stateful.
HTTP is a stateless protocol, still you are surfing just this moment a stateful website.

Re:Even if it is connectionless..

[0x0d0a]

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...)

Re:Even if it is connectionless..

[The Raven]

WTF do they do that, anyway?

Because a program that queries thousands of servers would take HOURS to query them all if it had to negotiate a connection, query, then break down the connection for EVERY SINGLE ONE of the servers it queries.

It's not uncommon for me to query 20 thousand servers in a few minutes. Doing this with a stateful method would take over an hour. Imagine downloading 20 thousand 500 byte images from 20 thousand web servers. With a well written program, you should be able to do 20 a second... IF you have Windows NT (or derivatives, like 2000 or XP) or Linux. Windows 9x wouldn't be able to do more than 3 or 4, because it can't handle the massive number of TCP connections that NT can.

Using UDP, on Windows 9x or NT or Linux, I can query 100-200 servers per second.

The advantages of a connectionless protocol are clear. Yes, we may need to consider an alternative, but don't bash them for stupidity when you don't know the first thing about what you're talking about.

That Explains It

[Sayten241]

I always knew that the 'D' in D-Day stood for DDoS.

Possible with Gnutella too

[Sanity]

Freenet developers Oskar Sandberg and Scott Miller did a presentation about a year ago at a O'Reilly P2P conference describing how Gnutella (and probably other P2P networks) could be used to initiate DDOS attacks in a similar manner.

Perhaps someone familiar with the Gnutella protocol can say whether this has been fixed yet.

Re:What did we always say..

[Anonymous Coward]

As much as I love the All Seeing Eye and I hate Gamespy, the problem exists in the games themselves, any games that support Gamespy. Next time read the article.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Funny, I discovered this almost a year ago

[Tom]

Including a posting to bugtraq. The original advisory is on my website. It's dated 13th March 2002.

Egress filtering

[yggdrazil]

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.

Re:Egress filtering

[StillAnonymous]

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.

Re:Another good reason to stick to the oldies...

[WolfWithoutAClause]

No. This is the electronic equivalent of the pizza attack; you ring up pizza restaurants and order for someone else; they get swamped with pizzas.

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.

Dont blame Gamespy!

[coene]

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.)

Security Analysis of Massively Multiplayer Online

[Amsterdam Vallon]

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

Re:Gotta love UDP

[Lukano]

Or you could just flash your BEFSR41 Linksys router and not have to worry;

http://www.linksys.com/download/firmware.asp?fwi d= 1

Intelligence = Security folks.

Not as big a problem as one might think.

[gmplague]

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.

Re:Not as big a problem as one might think.

[vekotin]

As I understand it, patching GameSpy alone won't help - you don't use GameSpy to flood the servers, but a nasty program to send spoofed UDP packets.

Which means patching all servers. As I see it, many gaming providers have a LOT of games running that are vulnerable. And as working for a games service provider myself, I think games go into three categories:
* too old to expect manufacturer/distributer support, but still played - sometimes 3rd party help available(fe. quakeworld, quake 2)
* new or at least still selling enough to interest, and the manufacturer/distributor actually cares about technology(fe. quake 3, half-life)
* new enough, but the manufacturer/distributer hasn't yet really understood why they should support people and companies running servers for them(fe. games from companies such as EA)

True, thanks to ISP's, this isn't a huge problem and I think its also reasonable to thank GameSpy in advance, I'm sure they'll make fixing this reasonably easy by doing their homework well. But still, this has a potential of making nasty stuff hit the fan.

Unfortunately, looking at the way many ISP's see online gaming, they might not give a damn about tuning their routers until they get a ton of packets stuffed in their cables.

here's hoping that GameSpy can work quickly on this...

This is old.

[utdpenguin]

This is jsut an adaptation of an old exploit I used to used back in the good old days. Me and some friends had hacked together an intranet version of pong back in hte early 70's. It didnt take us long to discover that if you sent multiple balls to the same court it was soon too muhc to handle and the players would all drop out, come over to your cube and beat the crap out of you.

This is the same technology they are talking about ehre.

Re:Another good reason to stick to the oldies...

[AndroidCat]

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. :^)

Feedback loop

[Mike McTernan]

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...

Several easy fixes

[billstewart]

OK, any definition of "easy" that requires getting millions of clients changed isn't _that_ easy :-) But if you're doing a new version of a server, it's worth doing things like this, and it's important to consider scale factors. It may be a big easier to get people to upgrade by sending out a message saying "upgrade to version N+1 or you'll get Fragged off the Net, send this email to everybody you game with right now!", but that's got its own problems :-)

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.