Multi-vendor Game Server (GameSpy) DDoS Attack 188
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)"
Well You Have To Give Them Credit (Score:5, Interesting)
Way to go GameSpy, yet another ounce of proof of a useless service for idjits.
Re:Well You Have To Give Them Credit (Score:2, Interesting)
Re:Well You Have To Give Them Credit (Score:2, Informative)
Re:Well You Have To Give Them Credit (Score:2)
A program combining this technique with queries to Gamespy's master servers (or even better, The All-Seeing Eye's scanner servers, they do some of the work for you) to find large servers with lots of players has the potential to be fairly devastating providing the network you launched the attack from allows spoofed UDP packets out.
The worst thing about this is that there isn't an easy fix for the issue. You basically have a couple different options:
1) Change the protocol. This is a problem because you'd have to change all the applications that use it as well as all the games. On top of that, servers handle TONS of these requests from legitimate sources and any overhead you add to them (ie. using TCP, implementing a handshake of some kind) is going to decrease server performance and increase network traffic, perhaps dramatically. You'd be at risk of turning this DoS on clients on its head and introducing an easy DoS for the game servers themselves by flinging a few thousand requests at them simultaneously.
2) Rate limit responses. It doesn't really matter, there are tens or hundreds of thousands of vulnerable game servers. One response from each of them with, say, 20 players or more, would be a huge amount of traffic.
3) Get network admins to stop spoofed UDP packets at the source. This is the real solution, but... yeah, right.
Re:Well You Have To Give Them Credit (Score:3, Informative)
I wrote a program for Quake 1 that flooded a server with false connections and disconnected legitimate users (http://online.securityfocus.com/bid/3051 [securityfocus.com]), and a friend changed 1 line of code to make my exploit do a "smurf" attack on a client (http://online.securityfocus.com/bid/3060 [securityfocus.com]).
Re:Well You Have To Give Them Credit (Score:2, Informative)
Re:Well You Have To Give Them Credit (Score:2)
Re:Well You Have To Give Them Credit (Score:2)
Read your Bugtraq, boys! There's a reason I don't allow UDP-based game servers to run inside my network.
Jouster
Re:Well You Have To Give Them Credit (Score:5, Insightful)
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.
Re:Well You Have To Give Them Credit (Score:3, Informative)
It was foolish to put "GameSpy" in the title of this article; it has nothing directory to do with GameSpy.
Jouster
Re:Well You Have To Give Them Credit (Score:2, Funny)
Since when are people on Gamespy not complaining about ping times?
hehehe (Score:5, Funny)
All in a days work.
*SNIFF* "God I love the smell of napalm^H^H^H^H^H^H severs burning in the morning"
What did we always say.. (Score:2, Interesting)
Re:What did we always say.. (Score:3, Informative)
Re:What did we always say.. (Score:1, Funny)
Dam them and their bloated propriatary , closed, middleware UDP, dam them all to hell.
Even if it is connectionless.. (Score:5, Informative)
Re:Even if it is connectionless.. (Score:1)
Re:Even if it is connectionless.. (Score:4, Informative)
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.. (Score:4, Interesting)
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.. (Score:4, Informative)
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.
Re:Even if it is connectionless.. (Score:2)
With a state machine it's really not difficult. Had I used
I agree that TCP is overused, and that depending on the OS to manage session state is not always the best solution. Certainly for a lightweight application like asking how many players are currently on a game server, a stateless ping-pong over UDP makes more sense. But TCP performance is not nearly as lousy as you claim, if you write the client properly.
Re:Even if it is connectionless.. (Score:2)
No Shit... (Score:2, Interesting)
UDP Reply: Challenge #HASHOFCURRENTTIME
UDP Message: VERIFY #HASHOFCURRENTTIME
UDP Reply: DATA
Problem Solved(TM)
Re:No Shit... (Score:2)
This is basically the same way TCP connection hijacking works, by guessing the TCP packet IDs coming from the server.
Re:No Shit... (Score:2)
Server: Challenge 876053
Client: Response 876053
Server: DATA
Yeah, I do this stuff for a living.
Jouster
Re:No Shit... (Score:2)
Let's try again:
Er, why bother hashing the current time? Just send random "x | -2^32 <= x < 2^32" and ask for it back.
Client: Stats, please.
Server: Challenge 876053
Client: Response 876053
Server: DATA
Yeah, I do this stuff for a living.
Jouster
Several easy fixes (Score:5, Interesting)
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 [networksorcery.com], 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 [cypherspace.org] 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.
That Explains It (Score:5, Funny)
Another good reason to stick to the oldies... (Score:2, Funny)
Re:Another good reason to stick to the oldies... (Score:5, Interesting)
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.
Re:Another good reason to stick to the oldies... (Score:2)
Re:Another good reason to stick to the oldies... (Score:2)
Funny, my bathroom is transmitting my IP Address.
You wouldn't believe the number of "Out of Body" experiences I've had there.
Re:Another good reason to stick to the oldies... (Score:5, Interesting)
Re:Another good reason to stick to the oldies... (Score:2)
Possible with Gnutella too (Score:5, Interesting)
Perhaps someone familiar with the Gnutella protocol can say whether this has been fixed yet.
Re:Possible with Gnutella too (Score:1)
Re:Possible with Gnutella too (Score:1)
Re:Possible with Gnutella too (Score:1)
Re:Possible with Gnutella too (Score:2)
That defense only partlysolves part of the problem (Score:2)
If you modify your fix a bit more - make the first answer packet small, and require a response before sending the big part, that could do the job. You could either do a table-driven approach, or just have the first exchange of packets be a cookie-like request/response, and require a valid cookie along with the actual query. If you want to get fancy, you can require the requester to do some calculation on the cookie value, e.g. hashcash, that burns a half second of CPU time on an average box, limiting the possible attack rate.
Re:That defense only partlysolves part of the prob (Score:2)
Re:That defense only partlysolves part of the prob (Score:2)
Oh, great (Score:1, Interesting)
I always knew GameSpy was a crappy product, but this just brings it to a whole new level.
Great (Score:2)
Comment removed (Score:5, Informative)
Re:Games don't support GameSpy (Score:1)
Re:Games don't support GameSpy (Score:1)
Re:Games don't support GameSpy (Score:1)
In addition, there are a number of other games which pretty much exclusively provide match-making through GameSpy like Fallout Tactics.
Certainly you can organize a game separately with a friend, but the developers and GameSpy are supporting one another. It is not simply GameSpy supporting certain interfaces with the game and servers that provide lists of active game hosts.
Re:Games don't support GameSpy (Score:2)
Not true. Gamespy licences their engine for use in some games. Many games strip down a lot of the features that are available in say, Gamespy 3D, but some games (like BF1942) use a surprising number of options.
Re: (Score:2)
Funny, I discovered this almost a year ago (Score:5, Interesting)
Re:Funny, I discovered this almost a year ago (Score:1)
Re:Funny, I discovered this almost a year ago (Score:2)
Re:Funny, I discovered this almost a year ago (Score:1)
Gotta love UDP (Score:3, Interesting)
Re:Gotta love UDP (Score:3, Interesting)
http://www.linksys.com/download/firmware.asp?fw
Intelligence = Security folks.
Re:Gotta love UDP (Score:1)
I didn't say that previous revisions of the firmware update fixed the problems, as the knowledge of the issue only became mainstream in the fall, -BUT- v.143 is known to and been proven to have fixed the exploit.
Pull Your Head Out Of Your Arse = Security
Re:Gotta love UDP (Score:2)
Re:Gotta love UDP (Score:1)
Cheers!
Spoofed packet question (Score:2, Insightful)
Re:Spoofed packet question (Score:2, Insightful)
Of late, more and more DDOS are not using spoofed IP's (thought egress filtering would certainly help).
Re:Spoofed packet question (Score:1, Informative)
Egress filtering (Score:5, Insightful)
They've had years to do that, and still don't.
Re:Egress filtering (Score:3, Interesting)
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:Egress filtering (Score:2)
I don't think you're quite getting it. What he's talking about is this:
Hacker A breaks into bystander B's PC, and uses it to send packets to server D with a spoofed source IP so it looks like the packets come from victim E.
Bystander B's ISP has certain ranges of IP addresses that they assign to their customers, including bystander B. Victim E's IP address is not one of those IPs. The ISP should set up their firewall so outgoing packets that do not originate within their own network are always blocked. Bystander B can still get his pr0n, because he's sending traffic out from his own IP address, but this kind of attack now fails.
Naturally, hacker A will just find some other bystander whose ISP doesn't firewall like this, but the more ISPs that do it, the harder that becomes.
And of course, this doesn't work when bystander B and victim E are on the same network, but very often they're not.
Server D can't really do much to stop this, other than look for flooding and try to block it. Server D doesn't know the packets didn't come from victim E. In the case of a game server, maybe the game server can tell which IPs belong to players and which don't, so if victim E isn't playing the game, requests for stats would be ignored. I don't know how practical that would be.
Re:Egress filtering (Score:3, Interesting)
Re:Egress filtering (Score:2)
But there are some issues.
For example some legitimate traffic will enter an ISPs network from outside on its way somewhere else; you do NOT want to kill that traffic, and by the time it reaches the firewall on the way out, the packet contains no record of how it got there.
Depending on network topology you may still be able to do it of course, but you'd have to do it with some care.
Re:Egress filtering (Score:2)
Geo Load ballancers, especialy the ones that use DNS timed race now this is somehting with a fixed Ip address but it's hard to keep up all sorts of exceptions. BTW this works pretty well.
Dual headed users (say DSL and Cable) that LB there outgoing requests. Now granted this is minor and isn't supposed to work but it's nice and gets you a good deal of redundancy.
Multihomed servers, they can send packets from any of there interface IP's via any of it's interface IP's some mail servers and DNS servers do this alot. Remember GigE is a new thing and servers have seen 100bt as a limitation for awhile.
And there are a lot of other issues. Now I have setup IPP's to do this and it works well enough at say a up to a tier 3 provider. This will give every multihomed carrier problems with traffic management especialy ones with old routers not taking more than a BGP default, not having the same carriers at every router, running disconnected AS's (Ok this is a no no but they do it)
Basic egress filtering should be in place for everybody all the martians should be blocked perferably at the ingress routers doing DSL, Cable and Modem agrigation. Yea this has some maintnence associated with it as the martians list changes every now and again as new
Re:Egress filtering (Score:2)
Lets say the ISP secretly wanted to capture the script kiddie demographic. It still wouldn't matter. Most packet kiddies use bots on comprimised computers, typically on different ISP's. It's this comprimised computer that's doing the damage. That customer couldn't care less about egress filtering, but the indended victim would definitely appreciate it. You can argue P2P has valid uses, even if 99% or more of the data going over it is in violation of copyright. The only people who have a legitimate need for sending packets who's source IP address didn't originate from that network are servers that have loadbalanced upstreams over several ISP's. However, it is easy enough for the ISP to allow those IP addresses through assuming they permit that type of activity.
-Restil
Isn't this self-correcting? (Score:2, Insightful)
Re:Isn't this self-correcting? (Score:2)
In fact you're better off using multiple servers because that makes it harder to filter out at the firewall, if you're stupid enough to do this kind of attack that is.
Dont blame Gamespy! (Score:4, Interesting)
This is something that needs to be addressed by Game Developers (Valve, ID, etc.)
Re:Dont blame Gamespy! (Score:2)
They need to implement a state table or checksumming, something to ensure the validity of the remote host.
Re:Dont blame Gamespy! (Score:2)
Agreed. I'm amazed at the number of posters who don't understand what UDP is, or what it's used for.
They need to implement a state table or checksumming
I think a simpler method of ensuring validity is to make the first reply packet small (as small or smaller than the query) and then delay for a few hundred milliseconds.. if the client is valid, they get a (unnoticeable) delay at the beginning of the connection; if the client is spoofed, they let you know via a dest-unreachable message.
If the first reply packet is smaller than the query, then spoofing is almost pointless.. it becomes more effective to send the packets yourself, instead of bouncing them off the server.
Security Analysis of Massively Multiplayer Online (Score:4, Interesting)
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:Security Analysis of Massively Multiplayer Onli (Score:2)
Half-Life.east.won.net (Score:2, Informative)
Magnification isn't that high (Score:2)
Not as big a problem as one might think. (Score:5, Interesting)
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. (Score:3, Insightful)
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...
Re:Not as big a problem as one might think. (Score:2)
Its as simple as:
I am ISP.
For data coming INTO my router from the Internet, is the _source_ ip from my block of IPs?
If yes, drop it silently and forget it ever existed.
For data going OUT of my router to the Internet, is the _source_ ip from my block of IPs?
If NO, drop it silently and forget it ever existed.
There, that fixes 100% of all spoof attacks from you or your users/customers, and fixes 100% of the spoof attacks of outsiders attempting to pretend to be one of your own machines.
In two filtering rules no less!
Ideally you would do filtering on both source and destination IPs, as well as filter out private IP space.
If a device is not capable of doing this, it is not a router, but a bridge or switch/hub, and should not be used for your internet connectivity.
why stop at gamespy traffic? (Score:1)
Most of them have small responses (Score:2)
Just DOS (Score:1)
Re:Just DOS (Score:1)
Say you are requesting at 14KB/s. Per server, at a 400 times rate, this is is 5,600KB/s. Do this to 100 servers and bam, you have ~546mb coming at you per second. This from a standard 128Kb/s upload cable service. Think of the possibilities
Re:Just DOS (Score:1)
My apologies
Re:Just DOS (Score:2)
This is old. (Score:3, Funny)
This is the same technology they are talking about ehre.
DOS not DDOS (Score:1, Redundant)
This attack can take down the "source server" as well as the destination.
Hoax! (Score:1)
Goatasaur was killed by Yourname.
"omg someone must be ddosing the server"
proof of concept code (Score:1, Interesting)
Feedback loop (Score:4, Interesting)
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...
Most firewalls block that (Score:2)
Re:Most firewalls block that (Score:2)
That is a nasty attack, but most firewalls of any sort block packets from the outside pretending to be from the inside, since there are _way_ too many Bad Things that can be done otherwise,
Phew! Let's hope Jolt have good firewalls!
Also, it's actually not as nasty an attack as it looks, because the server is probably on an Ethernet behind a router
Erm, it will probably loop straight back in the computer (at the IP layer) without even touching the network device since the source IP address would become that of the server! (Assuming not blocked by a firewall, as you point out)
Re:Feedback loop (Score:2)
All I can say is... (Score:1, Informative)
Re:All I can say is... (Score:2, Informative)
Possible solution (Score:2, Interesting)
Possible fix already in Unreal based games (Score:2, Informative)
Re:Remember, (Score:1)