Slashdot Mirror

← Back to Stories (view on slashdot.org)

Multi-vendor Game Server (GameSpy) DDoS Attack

Posted by Hemos on from the how-many-games-do-you-have dept.

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

41 of 188 comments (clear)

  1. Well You Have To Give Them Credit by Lukano · · Score: 5, Interesting

    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.

    1. Re:Well You Have To Give Them Credit by ChazeFroy · · Score: 2, Informative

      This approach and idea is actually very old, and it has already been done (although not through Gamespy).

      I wrote a program for Quake 1 that flooded a server with false connections and disconnected legitimate users (http://online.securityfocus.com/bid/3051), 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).

    2. Re:Well You Have To Give Them Credit by freaksta · · Score: 2, Informative

      dcd3c.c was a DoS that used about 100 quake servers to send data to a specified target.. it's nothing new.. just another DoS kiddie.. prolly DoSing DALNET too.

      --


      Hrrm... I usually just sign my name.
    3. Re:Well You Have To Give Them Credit by quakeroatz · · Score: 5, Insightful

      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.

    4. Re:Well You Have To Give Them Credit by SirCrashALot · · Score: 2, Informative
      The idea here is that you don't need zombies. With such a large return ratio, you can have a single computer on dialup, 14.4 can take down a T1 if you read the article. Yes, it can be a DDos but the point is IT DOES NOT HAVE TO BE.
      This low amount of required upstream would allow a simple modem user to send a hefty DoS to a T1 or higher. (see example below)
    5. Re:Well You Have To Give Them Credit by goatasaur · · Score: 2, Funny

      "Mind you I wonder how many gamers on those servers were complaining about ping times when that was happening."

      Since when are people on Gamespy not complaining about ping times?

      --
      ~D:
    6. Re:Well You Have To Give Them Credit by Jouster · · Score: 2, Informative

      I'll take this opportunity to give you a message referring you to other posts on this thread. The All-Seeing Eye (which I've used, mind you, great program) does nothing to solve this problem.

      It was foolish to put "GameSpy" in the title of this article; it has nothing directory to do with GameSpy.

      Jouster

  2. hehehe by SuperDuG · · Score: 5, Funny
    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"

    --
    Ignore the "p2p is theft" trolls, they're just uninformed
  3. What did we always say.. by BesigedB · · Score: 2, Interesting

    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.

    1. Re:What did we always say.. by Anonymous Coward · · Score: 3, Informative

      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.

  4. Even if it is connectionless.. by grub · · Score: 5, Informative

    .. 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,
    1. Re:Even if it is connectionless.. by Yokaze · · Score: 3, Informative

      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.

      --
      "Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
    2. Re:Even if it is connectionless.. by 0x0d0a · · Score: 3, Interesting

      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
    3. Re:Even if it is connectionless.. by The+Raven · · Score: 3, Informative
      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.
      --
      "I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
  5. That Explains It by Sayten241 · · Score: 5, Funny

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

  6. Another good reason to stick to the oldies... by saskboy · · Score: 2, Funny

    I haven't left playing Doom II. I guess I'm safe.

    --
    Saskboy's blog is good. 9 out of 10 dentists agree.
    1. Re:Another good reason to stick to the oldies... by WolfWithoutAClause · · Score: 4, Interesting
      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.

      --

      -WolfWithoutAClause

      "Gravity is only a theory, not a fact!"
    2. Re:Another good reason to stick to the oldies... by AndroidCat · · Score: 4, Interesting

      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.
  7. Possible with Gnutella too by Sanity · · Score: 4, Interesting
    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.

  8. Comment removed by account_deleted · · Score: 4, Informative

    Comment removed based on user account deletion

  9. Funny, I discovered this almost a year ago by Tom · · Score: 5, Interesting

    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
  10. Gotta love UDP by cscx · · Score: 2, Interesting

    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.

    1. Re:Gotta love UDP by Lukano · · Score: 3, Interesting

      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.

  11. Spoofed packet question by Anonymous Coward · · Score: 2, Insightful

    Does anybody know how well spoofed packets traverse the internet? I know that "good netizens" drop spoofed packets, and that this really needs to be implmented on edge routers. Do enough service providers do this to have any real effects on these type of attacks?

    1. Re:Spoofed packet question by mrball_cb · · Score: 2, Insightful

      It needs to be done at the ISP level. Those at the core can't really do it because of the CPU horsepower it would require. Adding just a couple of ACLs reduces the throughput from maximum. Google for NANOG and search their archives (third link).

      Of late, more and more DDOS are not using spoofed IP's (thought egress filtering would certainly help).

  12. Egress filtering by yggdrazil · · Score: 5, Insightful

    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.

    1. Re:Egress filtering by StillAnonymous · · Score: 3, Interesting

      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.

    2. Re:Egress filtering by extra88 · · Score: 2, Interesting

      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?

  13. Isn't this self-correcting? by slyborg · · Score: 2, Insightful

    Maybe I'm missing something, but since the data volume sepends on the number of people on the server, and gamers are notoriously intolerant of lag, the attack will in effect kill its own datasource as well if it goes on for more than a few minutes. The players will just jump off and look for another server.

  14. Dont blame Gamespy! by coene · · Score: 3, Interesting

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

  15. Security Analysis of Massively Multiplayer Online by Amsterdam+Vallon · · Score: 3, Interesting

    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.
  16. Half-Life.east.won.net by ThreeZee · · Score: 2, Informative

    Among the other won.net server trackers, Half-Life.east.won.net, Half-life.west.won.net, and so on, are also able to be exploited in the same manner. They can return thousands of bytes for a 2 byte query. a 3000 byte response would be a 1500x magnification..

  17. Not as big a problem as one might think. by gmplague · · Score: 5, Interesting

    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
    1. Re:Not as big a problem as one might think. by vekotin · · Score: 3, Insightful

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

      --
      /v\
  18. This is old. by utdpenguin · · Score: 3, Funny
    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.

    --
    In Soviet Russia you dant have to put up with these crappy jokes
  19. Feedback loop by Mike+McTernan · · Score: 4, Interesting

    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
  20. Possible solution by SirCrashALot · · Score: 2, Interesting

    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.

  21. Re:All I can say is... by Justus · · Score: 2, Informative

    Personally, I found The All-Seeing Eye to be much less bloated than Gamespy 3D. I have both a registration to Gamespy 3D (which I originally got years ago) and to the Eye, and I never (never!) go back to using Gamespy any more, because the Eye is just that much faster.

    --
    Schlock Mercenary
  22. No Shit... by Talez · · Score: 2, Interesting

    UDP Message: GIVE ME STATS!
    UDP Reply: Challenge #HASHOFCURRENTTIME
    UDP Message: VERIFY #HASHOFCURRENTTIME
    UDP Reply: DATA

    Problem Solved(TM)

  23. Several easy fixes by billstewart · · Score: 4, Interesting
    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.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  24. Possible fix already in Unreal based games by Xenolith · · Score: 2, Informative

    There is a variable within the main Unreal ini file that lets the server admin determine how many UDP server queries per second to allow. Unfortunately this variable is set to unlimited by default. Can't think of this variable off of the top of my head.

    --

    Journal