Multi-vendor Game Server (GameSpy) DDoS Attack

Well You Have To Give Them Credit by Lukano · 2003-01-19 06:34 · 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.

Re:Well You Have To Give Them Credit by irc.goatse.cx+troll · 2003-01-19 06:37 · Score: 1, Interesting

None, Each server dosnt feel much of an effect since the load is spread out upon many different servers. Atleast, thats how it was when I used to do this a few years ago.

--
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
Re:Well You Have To Give Them Credit by ChazeFroy · 2003-01-19 06:46 · 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).
Re:Well You Have To Give Them Credit by freaksta · 2003-01-19 06:54 · 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.
Re:Well You Have To Give Them Credit by quakeroatz · 2003-01-19 07:15 · 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.
Re:Well You Have To Give Them Credit by SirCrashALot · 2003-01-19 07:41 · Score: 0

No, this attack targets one server. It's ingenious in design -- it just keeps asking for status/player list and so on. The request is very short, just a single word, but the response is very long, player names, ping times, and so on. But, it does target a single server. Its a dos not a Ddos.
Re:Well You Have To Give Them Credit by Anonymous Coward · 2003-01-19 07:43 · Score: 0

No, you're an idiot. The point is that there are hundreds of preinstalled ddos zombies out there. All you gotta do is send then each a request with a spoofed source ip and then they respond to that spoofed ip with their info. Thus DDOS-ing the target host. Jebus save me.
Re:Well You Have To Give Them Credit by SirCrashALot · 2003-01-19 07:58 · 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)
Re:Well You Have To Give Them Credit by goatasaur · 2003-01-19 10:03 · 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:
Re:Well You Have To Give Them Credit by KeyserDK · 2003-01-19 10:15 · Score: 1

Mod the above guy up. I would, but i dont have any mod points. It really has NOTHING to do with supporting gamespy. They didnt make up the way it works - id (Carmack?) did.

This query method originates from from the quake 1 game. Although i'm not sure if it's the quakeworld version or the original version quake. It's basicly leftover from the days when online fps gaming was in its infancy. Remember that half-life was developed on a licensed quake1 engine.

I really doubt any game developers was thinking about DDOS attacks when making games in 1996 (quake 1).

I think this method got so widespread use with counter-strike and the quake game, that new game developers just used the same method, without considering the security issues in the era of 'modern' internet.

--
still reading?
Re:Well You Have To Give Them Credit by Anonymous Coward · 2003-01-19 12:30 · Score: 0

It's a flaw in the UDP protocol not gamespy.
Re:Well You Have To Give Them Credit by zaffir · 2003-01-19 13:03 · Score: 1

If you like Gamespy's server scanning features, check out The All Seeing Eye (no, i don't work for them or anything). It's the best server browser i've seen - although it only supports first person shooters.

--
"Upon attaching the waterblock to my penis, I began to notice that I know nothing about computers." -- JRockway
Re:Well You Have To Give Them Credit by zatz · 2003-01-19 16:45 · Score: 1

I was actually using the same technique for disconnecting users from a netquake server as far back as 1998. The funny part is, I was using it to administer my clan's own server, because there was no way to ban users based on nick or IP from the server console yet.

--

Java: the COBOL of the new millenium.
Re:Well You Have To Give Them Credit by Jouster · 2003-01-20 02:53 · Score: 1

Yeah, I ran across this one quite some time ago.

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 by Jouster · 2003-01-20 02:57 · 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
Re:Well You Have To Give Them Credit by lewp · 2003-01-20 16:59 · Score: 1

The point he's making is, unlike what you said, the target isn't a single server. It doesn't have to be a server at all. You send requests ('status', 'players', whatever) to game servers and they send their large responses to the address you spoofed when you sent the request. Whoever has that address is your target, not the game server.

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.

--
Game... blouses.

hehehe by SuperDuG · 2003-01-19 06:34 · 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

I think I have had this happen to me by SeXy_Red · 2003-01-19 06:35 · Score: 0

I think I have seen this happen to me, there have been a few times where my firewall gets SLAMMED with packets from UDP game servers. This is just another reason why I hate UDP...

--

This sig was generated by a barrel of trained kittens for SeXy_Red (550409).

Re:I think I have had this happen to me by Anonymous Coward · 2003-01-19 08:08 · Score: 0

This is just another reason why I hate UDP.

If you "hate UDP", then you don't understand it.

This particular attack could have been carried out with ICMP, IGMP, GRE, ESP, or any one of a dozen other stateless protocols, if Gamespy used them instead of UDP.

But if you "hate" UDP so much, why don't you block it? (Hmm, is it because your internet connection would stop working?)

What did we always say.. by BesigedB · 2003-01-19 06:35 · 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.

Re:What did we always say.. by Anonymous Coward · 2003-01-19 06:45 · 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.
Re:What did we always say.. by Anonymous Coward · 2003-01-19 06:48 · Score: 1, Funny

...It might make developers think twice before using their bloated propriatary, closed, middleware ...,
Dam them and their bloated propriatary , closed, middleware UDP, dam them all to hell.
Re:What did we always say.. by Anonymous Coward · 2003-01-19 06:50 · Score: 0

Yes, because the problem had nothing to do with the games themselves, and had to do exclusively with the fact that some application was closed-source. I keep forgetting that open-source programs are error-free from day one.

Not that I don't enjoy a good open-source-vs-closed-source flamewar now and then, but I fail to see how your argument applies in this case.
Re:What did we always say.. by BesigedB · 2003-01-19 06:57 · Score: 0

Pah, I didnt mean it to be inflammatory. Better luck next time me.
Re:What did we always say.. by Anonymous Coward · 2003-01-19 08:02 · Score: 0

Speaking of articles:
Is the Digital Millennium Copyright Act Unconstitutional under Eldred v. Ashcroft?

Mail Chauvinism:The Magicians,the Snarkand the Camel-Ted Nelson

Flying in the Face of Infertility

Dancing around Web services

2002 Worst Manual Contest Winners

Even if it is connectionless.. by grub · 2003-01-19 06:37 · 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,

Re:Even if it is connectionless.. by dextr0us · 2003-01-19 06:40 · Score: 1

but then it wouldn't be udp....

--
"Martha Stewart can lick my Scrotum......do i have a scrotum?" -- Sharon Osbourne
Re:Even if it is connectionless.. by Anonymous Coward · 2003-01-19 06:47 · Score: 0

NFS works over UDP as an option and still verifies the xfers.
Re:Even if it is connectionless.. by Yokaze · 2003-01-19 06:58 · 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"
Re:Even if it is connectionless.. by 0x0d0a · 2003-01-19 09:08 · 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
Re:Even if it is connectionless.. by The+Raven · 2003-01-19 11:13 · 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.
Re:Even if it is connectionless.. by zatz · 2003-01-19 16:25 · Score: 1

I recently wrote an application which managed about 200 outbound TCP connections per second from a single thread. Each connection went through about three request/response steps before it was closed. Typically there were about 4000 simultaneous connections open, so the average lifetime would obviously be somewhere around 20 seconds.

With a state machine it's really not difficult. Had I used /dev/kqueue (this was on FreeBSD) instead of select(), it probably could have scaled up to the point of using all the network bandwidth available to the host.

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.

--

Java: the COBOL of the new millenium.
Re:Even if it is connectionless.. by 0x0d0a · 2003-01-19 16:36 · Score: 1

Ahhh...I see. I hadn't read the advisory -- I had thought that people were amplifying their attack off of the *meta*servers, not the servers. That makes more sense.

--
May we never see th

That Explains It by Sayten241 · 2003-01-19 06:38 · Score: 5, Funny

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

Another good reason to stick to the oldies... by saskboy · 2003-01-19 06:38 · 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.

Re:Another good reason to stick to the oldies... by WolfWithoutAClause · 2003-01-19 06:59 · 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!"
Re:Another good reason to stick to the oldies... by Junta · 2003-01-19 07:30 · Score: 1

'warning, your computer is broadcasting an IP address right now!' hehehe.

--
XML is like violence. If it doesn't solve the problem, use more.
Re:Another good reason to stick to the oldies... by AndroidCat · 2003-01-19 08:04 · 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.
Re:Another good reason to stick to the oldies... by rela · 2003-01-19 08:45 · Score: 1

Couldn't you have found another source? Saying something intelligent, then following it with a link to grc.com is like buying a limo and then hacking mercilessly at the interior and paint job with a sword.
It's still a limo but you've just fucked it up so bad that what's the point?
Re:Another good reason to stick to the oldies... by AndroidCat · 2003-01-19 09:20 · Score: 1

He might have crackpot ideas now and then, but the page isn't a bad overview explaination. (Have you read it?)

--
One line blog. I hear that they're called Twitters now.
Re:Another good reason to stick to the oldies... by saskboy · 2003-01-19 09:26 · Score: 1

I was just kidding, because I didn't think Doom II had support for playing over the Internet, just LANs.

--
Saskboy's blog is good. 9 out of 10 dentists agree.
Re:Another good reason to stick to the oldies... by WolfWithoutAClause · 2003-01-19 09:40 · Score: 1

I did wonder. Still, you are obviously vulnerable whilst online and posting to Slashdot ;-)

--
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"
Re:Another good reason to stick to the oldies... by shepd · 2003-01-19 09:56 · Score: 1

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

Are you so sure?

--
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Re:Another good reason to stick to the oldies... by matrix29 · 2003-01-20 10:09 · Score: 1

'warning, your computer is broadcasting an IP address right now!' hehehe.

Funny, my bathroom is transmitting my IP Address.

You wouldn't believe the number of "Out of Body" experiences I've had there.

--
"Face it, a nation that maintains a 72% approval rating on George W. Bush is a nation with a very loose grip on reality.

Possible with Gnutella too by Sanity · 2003-01-19 06:39 · 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.

Re:Possible with Gnutella too by e12532 · 2003-01-19 06:43 · Score: 0

theoretically it would be possible with anything serving udp packets... good thing the only packets that go out of my box are tcp/ip :)
Re:Possible with Gnutella too by 56ker · 2003-01-19 07:09 · Score: 1

Talking of DDOS attacks - is anyone experiencing a slowdown very similar to that caused by a DDOS attack? Eg website requests time out, high packet loss etc.

--

Video Game cheats, hints a
Re:Possible with Gnutella too by wik · 2003-01-19 07:24 · Score: 1

Yes, but it's probably just college students returning to high-bandwidth dorm connections at school.

--
/ \
\ / ASCII ribbon campaign for peace
x
/ \
Re:Possible with Gnutella too by AndroidCat · 2003-01-19 08:16 · Score: 1

Don't be too sure. I'm not sure that SYN/SYNACK attack couldn't just request a TCP/IP socket. (Note the words "I'm not sure" please. :^)

--
One line blog. I hear that they're called Twitters now.
Re:Possible with Gnutella too by schon · 2003-01-19 08:22 · Score: 1

theoretically it would be possible with anything serving udp packets

Actually, it's only possible if the thing serving the UDP packets sends out large amounts of data from a small query.

That's how these things work - you send a small piece of data, and the server sends back a large amount of data, without verifying that the request is valid.

The solution (of course) is to verify the request before the server sends the large amount of data..

With the Gamespy problem, the simplest fix is to make the first answering packet smaller than the query used (just an "are you here"), then delay (say, a few hundred milliseconds) before sending the rest of the answer.. If the request is bogus, they should get a destination unreachable message from the first packet.. if the request is OK, then all the client will notice is a 1/2 second delay.

good thing the only packets that go out of my box are tcp/ip

You're saying you never make DNS queries?

OK, maybe all you do is surf, but I bet you're still using DNS.
Re:Possible with Gnutella too by 0x0d0a · 2003-01-19 09:46 · Score: 1

Gnutella (at least traditionally) used only TCP. I'm thinking that they're talking about something higher-level, if this talk was a full year ago.

--
May we never see th

Oh, great by sean23007 · 2003-01-19 06:45 · Score: 0, Interesting

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.

Great by RedWolves2 · 2003-01-19 06:48 · Score: 1

now the whole slashdot community is going to slashdot gamespy to see if they are up. Double whammy.

Re:Great by Anonymous Coward · 2003-01-19 07:57 · Score: 0

GameSpy regulary posts articles that get linked from Slashdot. They're not sweating the traffic.

Comment removed by account_deleted · 2003-01-19 06:49 · Score: 4, Informative

Comment removed based on user account deletion

Funny, I discovered this almost a year ago by Tom · 2003-01-19 06:52 · 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

Re:Funny, I discovered this almost a year ago by ThreeZee · 2003-01-19 06:57 · Score: 1

I believe they do have your document listed in the advisory.
Re:Funny, I discovered this almost a year ago by BesigedB · 2003-01-19 07:04 · Score: 0

So.... you reported it a year ago and it has only become a 'mainstream security' issue this week. Interesting.
Re:Funny, I discovered this almost a year ago by Tom · 2003-01-19 07:07 · Score: 1

Yepp, as "related documents". I fail to see the difference, though. Maybe I've missed the critical point, but from what I read it's the exact same exploit, just against a different game.

--
Assorted stuff I do sometimes: Lemuria.org
Re:Funny, I discovered this almost a year ago by Xacid · 2003-01-19 07:30 · Score: 1

So does that mean that now that it's mainstream the kiddies will think it's uncool and will stop doing it? ;) I never understand why these people tend to be so destructive of the net. We should be fighting "da man" or something. Not each other.
Re:Funny, I discovered this almost a year ago by Anonymous Coward · 2003-01-19 08:57 · Score: 0

and there was a 13 year old kid on irc doing this with quake servers, in 1997.

Can those game servers be sued then? by niom · 2003-01-19 06:53 · Score: 0

Maybe those game servers can be sued for damages because their defective security is what allowed the DDoS attacks.

--
-- Repeat with me: "There is no right to profits".

Re:Games don't support GameSpy by Drakin · 2003-01-19 06:53 · Score: 1

Actually, a number of games are useing Gamespy as their in game online game finder... Unreal Tournament 2003, Neverwinter Nights, Battlefield 1942, all have Gamespy packaged within them. Probably plenty of others

Re:Games don't support GameSpy by ThreeZee · 2003-01-19 06:54 · Score: 1

If you read through the advisory, you'll probably understand a little more clear that it's not just a gamespy related problem. Games that easily return huge query responses from little data are the problem.. but this isn't limited to games, as it can also be found even from standard open ports on Windows XP, and so on. UDP Spoofing isn't new, this advisory is just highlighting a source that returns a huge amount of data by sending so little.

Gotta love UDP by cscx · 2003-01-19 06:55 · 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.

Re:Gotta love UDP by Lukano · 2003-01-19 07:16 · 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.
Re:Gotta love UDP by Lukano · 2003-01-19 07:42 · Score: 1

*sigh*

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 by cscx · 2003-01-19 07:46 · Score: 1

That's good to know. It's just after about a year of being repeatedly told about this, they completely ignored the community, which made me think that they would never get around to fixing it. So I construed your original post as an uninformed "heh he should just update the firmware...idiot..." post. Sorry.
Re:Gotta love UDP by Lukano · 2003-01-19 07:51 · Score: 1

Offtopic I know, but no worries... Being a manager with a large-box franchised computer retailer in Canda, I've had to field COUNTLESS customer inquiries regarding this issue with that particular router (which we sell more than any other brand/model). So I am and was fairly confident that the information I was giving them was correct and up-to-date.

Cheers!

Spoofed packet question by Anonymous Coward · 2003-01-19 06:56 · 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?

Re:Spoofed packet question by mrball_cb · 2003-01-19 07:31 · 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).
Re:Spoofed packet question by Anonymous Coward · 2003-01-19 07:47 · Score: 1, Informative

No it has little to do with CPU power at the core. It has to do with the actual possibility of doing it. The only place you can do proper egress filtering is at the edge. Nowehere else. Jebus save me.

Egress filtering by yggdrazil · 2003-01-19 06:58 · 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.

Re:Egress filtering by BesigedB · 2003-01-19 07:14 · Score: 0

My isp support people when P2P apps dont work. They do this because if they blocked it their customer base would go down, and they know it.
The same situation might apply here where their customer base may go down if their 'leet haxor' users found out they couldnt pretend to be microsoft.com.
Re:Egress filtering by StillAnonymous · 2003-01-19 08:22 · 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.
Re:Egress filtering by Restil · 2003-01-19 08:43 · Score: 1

You might be sarcastic, but lets say you aren't.

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

--
Play with my webcams and lights here
Re:Egress filtering by Phroggy · 2003-01-19 09:08 · Score: 1

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.

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.

--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Re:Egress filtering by extra88 · 2003-01-19 09:08 · 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?
Re:Egress filtering by silas_moeckel · 2003-01-19 09:27 · Score: 1

There is one problem with this at least Mobile IP it's a spec it's designed to work and it dosent provide a return path like a VPN. Now granted most people would be better served by a VPN than using mobile IP. Next is ou have to remember there are a LOT of things that assume packets can originate from any address.

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 /8 are given out. It's easier to tell an aggrigation router to only allow packets say from the /32 of a modem user than make all the edge routers filter things.

--
No sir I dont like it.
Re:Egress filtering by WolfWithoutAClause · 2003-01-19 09:34 · Score: 1

Well, setting up a firewall to do that isn't hard at all.
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.

--
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"
Re:Egress filtering by Anonymous Coward · 2003-01-19 11:01 · Score: 0

How is your very long and thorough description any different from what he said?

Seems to me you just said exactly the same thing.
Re:Egress filtering by dhammabum · 2003-01-19 11:55 · Score: 1

Yes I agree ISPs aren't being responsible, but they probably will never do anything until they are forced through legislation.

But most DDoS attacks are from compromised machines direct to the victim using real addresses - egress filtering doesn't help.

And, no, egress filtering is not a big deal. You actually filter at the ingress point (where the client connects to the isp) - that way it doesn't affect throughput at the isp's boundary.

--
I am not a robot. I am a unicorn.
Re:Egress filtering by fimbulvetr · 2003-01-19 13:53 · Score: 1

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

Clueless eh?

If I am assuming correctly, the general public in the world has had years to pick up trash in the ditches and fields left by a small percentage of the non-caring population. But I still see very few people doing this, possibly the same percentage of ISP's who perform these big brother techniques.

Come to think of it, what sysadmin is going to give you the time of day?

With internet service battling for the ~$4.95/mo arena, I don't see much use in hiring but one sysadmin for this position, and making sure he can handle hundreds of thousands of people a month with his setup, pay him $200k/yr, and outsource the tech support.

The day ISPs start keeping the bad guys away from you is the day you convince the general public that internet access is really worth that few extra bucks, and next time, choose your local ISP.

Once this is accomplished, I'll configure my router to that specification, and we can go on our merry ways.

Until then my routers stay the way they are, you can have your "Make the internet a safer place" cult, and we may see each other again.

My schema is designed for maximum scalibility, minimum filtering (due to load), and most of all, 99.999.
Re:Egress filtering by Anonymous Coward · 2003-01-19 17:22 · Score: 0

ISPs have mac addresses and can associate them with ip addresses, just stamp outgoing packets with the correct IP Address as it passes through without checking based on mac addr.
Re:Egress filtering by porttikivi · 2003-01-20 23:14 · Score: 1

It was really called "ingress filtering", not egress, see http://community.roxen.com/developers/idocs/rfc/rf c2827.html.

Ingress in IETF parlance means "coming in to the big Internet", and that's where spoofed source needs to be checked, by end-user routers and various levels of transit traffic operator routers connecting to ever bigger networks.

It seems though, that language is eroding, and the concepts of ingress and egress are now confusingly relative, to judge by the One Truth of Google.

--
Anssi Porttikivi / app@iki.fi

Isn't this self-correcting? by slyborg · 2003-01-19 07:02 · 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.

Re:Isn't this self-correcting? by BesigedB · 2003-01-19 07:10 · Score: 0

The server will still return some data to the effect of 'no players' - albeit of a lesser size.
Re:Isn't this self-correcting? by WolfWithoutAClause · 2003-01-19 07:39 · Score: 1

You're missing the fact that the target isn't the game server, the game server is the weapon, the target is elsewhere e.g. www.slashdot.org ;-( and there are tens of thousands of servers out there you can use simultaneously; so the users of the game server probably wouldn't notice.
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.

--
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"
Re:Isn't this self-correcting? by TechMangler · 2003-01-19 08:45 · Score: 1

I seem to have been victim to this. My old athlon 800 seemed like a perfect platform for my gateway/ firewall and with more than enough horsepower to run a Q3 server under Slack 8.1.
Untill I heard about this, I could never figure out what happened when it got 8 or more players - the pings would hit the ceiling, the gamers would bail, and the traffic went nuts until I shut down Q3. I couldn't even surf the web.
So - now off to find out what to block, and I should be back in biz.

Dont blame Gamespy! by coene · 2003-01-19 07:04 · 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.)

Re:Dont blame Gamespy! by Anonymous Coward · 2003-01-19 07:11 · Score: 0

What exactly do Valve and ID have to do with the UDP protocol though?? Besides obviously making games that use it. Maybe the people who designed UDP should plan an update, UDP2
Re:Dont blame Gamespy! by BesigedB · 2003-01-19 07:17 · Score: 0

But that would need support from old and new operating systems alike. Unless this protocol was bundled with the games it may be more trouble than it was worth.
Re:Dont blame Gamespy! by coene · 2003-01-19 07:45 · Score: 1

This has nothing todo with the UDP protocol. Developers understand the limitations of the protocol, and as anyone who had done any real work with sockets programming understands, you must choose your protocol and work around its limitations.

They need to implement a state table or checksumming, something to ensure the validity of the remote host.
Re:Dont blame Gamespy! by schon · 2003-01-19 08:31 · Score: 1

This has nothing todo with the UDP protocol. Developers understand the limitations of the protocol, and as anyone who had done any real work with sockets programming understands, you must choose your protocol and work around its limitations.

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.

Come on, you're not even trying now. by Anonymous Coward · 2003-01-19 07:07 · Score: 0

Even the pigs thing was redone. Disappointing.

CounterStrike no longer vulnerable Sunday January 19, @12:57 Score:0, Troll attached to Multi-vendor Game Server (GameSpy) DDoS Attack Part of the team Sunday January 19, @08:16 Replies:5 Score:-1, Troll attached to FreeBSD 5.0 Available From the BSD 5.0 Bugs Page Sunday January 19, @08:10 Replies:4 Score:-1, Troll attached to FreeBSD 5.0 Available More than 1.1 billion pigs are killed each year Sunday January 19, @08:05 Replies:14 Score:-1, Offtopic attached to FreeBSD 5.0 Available You're being naive, good sir Saturday January 18, @23:06 Replies:4 Score:0, Troll attached to MIT Spam Conference Conclusions More than 1.1 billion pigs are killed each year Saturday January 18, @22:59 Replies:5 Score:-1, Offtopic

Security Analysis of Massively Multiplayer Online by Amsterdam+Vallon · 2003-01-19 07:13 · 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.

Half-Life.east.won.net by ThreeZee · 2003-01-19 07:17 · 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..

Not as big a problem as one might think. by gmplague · 2003-01-19 07:18 · 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

Re:Not as big a problem as one might think. by vekotin · 2003-01-19 07:32 · 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\
Re:Not as big a problem as one might think. by dissy · 2003-01-19 14:21 · Score: 1

You dont even need to go though all the work of setting up packet mangling and mac address lookup and all of that other time consuming stuff.

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.
Re:Not as big a problem as one might think. by psychos · 2003-01-19 17:26 · Score: 1

I'm not quite sure where you get your information from, but I seriously doubt any providers are specifically rewriting spoofed udp packets into legitimate addresses. Routers simply do not perform tasks like that.

Providers are not dropping/rewriting just spoofed udp. They're either dropping all spoofed traffic, or letting all traffic through. Why would they apply this rewriting only to udp if they were indeed doing it? The simple answer is that they are not doing it.

why stop at gamespy traffic? by wuchang · 2003-01-19 07:20 · Score: 1

you may as well throw in all of those pesky UDP services on the list.

Remember, by LiftOp · 2003-01-19 07:21 · Score: 0, Offtopic

Dilute! Dilute! OK!!!

Re:Remember, by Anonymous Coward · 2003-01-19 07:28 · Score: 0

Do not drink soap!
Re:Remember, by ElJosho · 2003-01-19 08:11 · Score: 1

We're ALL-ONE or none! OK!

Well. by Dest · 2003-01-19 07:34 · Score: 0, Interesting

You kind of wonder why programmers wouldn't put some sort of UDP reply limitation in the query system of all these games.

Yes they can... by Anonymous Coward · 2003-01-19 07:40 · Score: 0

Games can have internal matchmaking screens using Gamespy's own API.

Re:Security Analysis of Massively Multiplayer Onli by waytoomuchcoffee · 2003-01-19 07:44 · Score: 1

This is hardly a research paper. It is more like a 20-page powerpoint presentation that doesn't really give any new info. Am I missing something here?

Re:Games don't support GameSpy by PhoenixK7 · 2003-01-19 07:46 · Score: 1

I'd beg to differ. The multiplayer expansion for Civ III, Play the World is GameSpy branded for all of the pre game setup (this is when the Civ III application has been launched, not while you're still using GameSpy Arcade).

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 by waytoomuchcoffee · 2003-01-19 07:47 · Score: 1

Games don't support GameSpy, GameSpy supports games.

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.

Just DOS by aclaudet · 2003-01-19 07:47 · Score: 1

Isn't this just a DoS attack rather than a DDoS attack. Seems like it's coming from a single node.

Re:Just DOS by Neophytus · 2003-01-19 07:56 · Score: 1

If a user sends out packets to, say, 100 servers you get ~100 times the number of packets. So long as the user can reliably output the small request packet to each server the 400 times responce factor still applies.

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 by Neophytus · 2003-01-19 08:01 · Score: 1

And you know what. I got my sums wrong. There is a finite responce for 128Kbps of 5,600KB. I applied the formula to an upload rate of 1400KB/s upload.

My apologies
Re:Just DOS by AndroidCat · 2003-01-19 08:38 · Score: 1

And someone could easily use a horde of zombie machines to generate the packets, resulting in an unspeakable amount of data coming at the poor victim.

--
One line blog. I hear that they're called Twitters now.

Wait a second... by Anonymous Coward · 2003-01-19 07:49 · Score: 0

I didn't expect QuakeX to be out for at LEAST another 30 years.

Re:Games don't support GameSpy by Anonymous Coward · 2003-01-19 07:49 · Score: 0

It doesn't matter - as long as it is a GameSpy server, you can use it to attack any remote host whose IP Address you know.

It'll harm performance on the server, but it'll harm the remote host far more.

This is old. by utdpenguin · 2003-01-19 07:49 · 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

DOS not DDOS by SirCrashALot · 2003-01-19 07:55 · Score: 1, Redundant

A DDOS attack is a distributed denial of service attack, one where many servers all send packets to take down a network. As this article states, it is a dos attack. You hit one server at a time. If you send packets to multiple servers, then it can be a ddos, but not in the sense where there is very little disruption from the source of the attack.
This attack can take down the "source server" as well as the destination.

Comment removed by account_deleted · 2003-01-19 07:56 · Score: 1

Comment removed based on user account deletion

Hoax! by goatasaur · 2003-01-19 08:02 · Score: 1

This is just an excuse for people to blame on lag.

Goatasaur was killed by Yourname.
"omg someone must be ddosing the server"

--
~D:

Re:Hoax! by girish · 2003-01-19 21:43 · Score: 1

Hehe, just reminded me of this:
blamelag.jpg

proof of concept code by Anonymous Coward · 2003-01-19 08:05 · Score: 1, Interesting

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

Feedback loop by Mike+McTernan · 2003-01-19 08:10 · 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

Re:Feedback loop by zatz · 2003-01-19 16:47 · Score: 1

There was an attack on early versions of Quake 2 which worked like that.

--

Java: the COBOL of the new millenium.

All I can say is... by Anonymous Coward · 2003-01-19 08:14 · Score: 1, Informative

that Gamespy is the biggest pain-in-the-you-know-what anyways. Bioware for some reason chose to use Gamespy for Neverwinter Nights, and it had to re-ping all the servers everytime you tried to connect to a server, but were told the server was full (even if it said the server had 39/40 people when you pinged it earlier). And then there's how the game publishers are too lazy to host their own patches, so they let jerkoffs like Gamespy's FilePlanet host the patches. I think they do it because they know they can get away with it.

Re:All I can say is... by Egekrusher2K · 2003-01-19 08:45 · Score: 1

Am I the only one here that actually likes using gamespy? It updates the servers much faster than the game engines can, and also detects WAY more game servers than the games do themselves. Try using Gamespy 3D instead of that Arcade BS. Yes, I will agree, Gamespy Arcade sucks. So? Use Gamespy 3D. They're NOTHING alike. It's like going from Win XP (Arcade, bloatware), to using TurboLinux (Gspy 3D, simple, powerful).

--
Listen to my experimental-industrial-techno!
Re:All I can say is... by Justus · 2003-01-19 09:53 · 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

Re:Security Analysis of Massively Multiplayer Onli by DerOle · 2003-01-19 08:41 · Score: 1

No, you're missing nothing at all.
Hardly any usefull, interesting or new information in this "research paper".
Just a couple of action points...

Maybe he hates stateless protocols by hackwrench · 2003-01-19 09:01 · Score: 1

and UDP is the most misused. Or maybe he would hate the other stateless protocols if they were as misused as much as UDP...You should try playing this game sometime.

That defense only partlysolves part of the problem by billstewart · 2003-01-19 09:18 · Score: 1

There are two different kinds of attacks here, and your split-response defense only solves part of one of them. The attacks work because a small UDP query gets a big UDP response, so you can get a Gamespy server to send out 400 times more data than it receives, and by forging the UDP origin, you can direct it places.

One attack is to swamp a third-party target's Internet pipe by sending forged UDP requests to the Gamespy server, which has a much bigger Internet pipe than the target (or sending them to a bunch of Gamespy servers, which at least have a much bigger combined bandwidth.) Your defense doesn't solve that, because the destination is reachable - it's an existing IP address, and you can pick some UDP port that's probably valid, such as 53.
Another attack is to swamp the server's Internet pipe by sending lots of forged requests "from" lots of places, which works because your 5kbps of requests generate 2Mbps of response, killing a T1, or your 128kbps of dsl/cable upstream generates 50Mbps of response, killing a T3 and doing a pretty good job on a 100Mbps ether. One variation on this is to forge all the requests as "from" one target, but a probably more successful approach is to spread the destination around to a large number of addresses. If the addresses are invalid, then your defense will help, but if they're valid IP addresses, it won't.

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.

--

Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks

Not "checksumming", but "authentication" by apankrat · 2003-01-19 09:19 · Score: 1

Their main problem is in *application* protocol (the one on top of the UDP) being stateless. Adding simple state machine implementing client's registration will resolve the problem.

The first client's message says 'hi, i want to talk to you, register me', the server generates an ID for client's IP/port pair and sends ID back to the client. All subsequent packets that client sends include this assigned ID and thus ID serves as a simple 'authentication token' to the server.

It is still possible to spoof an inital message, but the trick is to keep server's registration response to the minimum and rate limit registration requests on the server's firewal.

--
3.243F6A8885A308D313

Possible solution by SirCrashALot · 2003-01-19 09:29 · 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.

Magnification isn't that high by billstewart · 2003-01-19 09:30 · Score: 1

At the data level it is, but the whole query includes the UDP and IP headers, which are about 40 bytes, so it's really only ~75:1 magnifaction. (Modem users can do compressed PPP and get somewhat smaller headers for somewhat bigger effect.) Still an attractive nuisance.

--

Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks

Re:Magnification isn't that high by ThreeZee · 2003-01-19 09:42 · Score: 1

Bill, you are correct. My mistake.

I wish Gamespy would rollover and die. by angelkey · 2003-01-19 09:30 · Score: 0, Interesting

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

Most of them have small responses by billstewart · 2003-01-19 09:33 · Score: 1

A typical query for DNS or daytime or SNMP whatever gets a response that's similar in size to the query; this attack is fun because you can get a 400:1 multiplication.

--

Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks

Most firewalls block that by billstewart · 2003-01-19 09:36 · Score: 1

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, more of them security breaches than denial of service. Also, it's actually not as nasty an attack as it looks, because the server is probably on an Ethernet behind a router, so the loopback happens on the 100Mbps Ether segment, and doesn't try to go out the T1 Internet pipe.

--

Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks

Re:Most firewalls block that by Mike+McTernan · 2003-01-19 12:10 · Score: 1

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)

--
-- Mike

Re:That defense only partlysolves part of the prob by MulluskO · 2003-01-19 10:10 · Score: 1

I think one would almost be required to be fancy, because this is all UDP. That is, because the connection is stateless, a response might also be spoofed.

--

Too busy staying alive... ~ R.A.

Re:Wow. by Anonymous Coward · 2003-01-19 10:11 · Score: 0

Stupid. Just about every new vulnerability comes from information in past vulnerabilities.

No Shit... by Talez · 2003-01-19 10:44 · Score: 2, Interesting

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

Problem Solved(TM)

Re:No Shit... by anonymous+loser · 2003-01-19 11:54 · Score: 1

All you'd have to do to defeat your solution would be to send along a few extra packets that guessed the hash (based on ping time, for example).

This is basically the same way TCP connection hijacking works, by guessing the TCP packet IDs coming from the server.
Re:No Shit... by Talez · 2003-01-19 21:38 · Score: 1

Your little "defeat" involves the server being extremely synchronised to your clock, and knowing the timezone the server is in.

Otherwise if you're hashing the time at the millisecond level (which you should) you're going to have to fake a few hundred thousand hashes.

Not to mention you could just stop the transaction if they replied with the wrong verify hash.
Re:No Shit... by Jouster · 2003-01-20 04:09 · Score: 1

Er, why bother hashing the current time? Just send random "x | -2^32 Client: Stats, please.
Server: Challenge 876053
Client: Response 876053
Server: DATA

Yeah, I do this stuff for a living.

Jouster
Re:No Shit... by Jouster · 2003-01-20 06:11 · Score: 1

Dang preview button!

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 by billstewart · 2003-01-19 10:45 · 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

IT IS SO OBVIOUS by aphor · 2003-01-19 11:05 · Score: 1

I am truly sorry you even had to post this message, but someone had to. If you're going to forward packets, you should decide whether, not just whither to retransmit them!

--
--- Nothing clever here: move along now...

Re:That defense only partlysolves part of the prob by billstewart · 2003-01-19 11:26 · Score: 1

Just because the connection is stateless doesn't mean the protocol has to be; cookies and their relatives are a traditional way to work around that. Have the server generate a random cookie value and store it, and require the client to provide a valid cookie as part of the query. You can either have the cookie contain information about the client (its IP address or whatever), or not bother about that, and trash any cookies older than a few seconds. The only important thing is making sure that cookie values aren't easily predictable, so use a 64-bit random number or something that's not a timestamp.

--

Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks

Re:That defense only partlysolves part of the prob by Anonymous Coward · 2003-01-19 12:10 · Score: 0

Right, fancy.

Possible fix already in Unreal based games by Xenolith · 2003-01-19 19:23 · 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

This topic should have GameSpy's name removed :) by Anonymous Coward · 2003-01-19 22:07 · Score: 1, Interesting

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.

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

Well ... by Amiasian · 2003-01-19 23:21 · Score: 1

Just out of curiosity on the lines of this whole rethinking thing, can someone explain to me what a technology like Apple's rendezvous do for gaming?

Re:Well ... by Anonymous Coward · 2003-01-20 02:19 · Score: 0

Not much, Mac users just get GameRanger.

It's what GheiSpy wishes it could be.

What about? by Amiasian · 2003-01-20 00:09 · Score: 1

Yes it?s time to rethink client/server game querying ...
Out of curiosity, as I don't quite understand the technology behind it, how would something like Rendezvous work for such a purpose? It's open-source, intended for cross-platform use and supposedly automatically can find and query servers, I guess. Is that how this thing works?

Sorry to reply to my own comment. by Amiasian · 2003-01-20 00:12 · Score: 1

The URL should be: http://www.apple.com/macosx/jaguar/rendezvous.html

Funny? by mrselfdestrukt · 2003-01-20 00:54 · Score: 1

>Funny thing, isn't it? (originally found on heise.de)"
No, it's not. Sounds like any DDOS attack. most modern firewalls and routers can filter and detect this for you. As soon as it sees something that looks like this it can block and reroute.
Not rocket science.

--
"I used to have that really cool,funny sig ,but it got stolen."

Re:That defense only partlysolves part of the prob by tangent3 · 2003-01-20 01:55 · Score: 1

good point.

Old and not related to gamespy by madsdyd · 2003-01-20 02:44 · Score: 1

First of all, this have nothing to do with game spy, it is related to the servers.

Secondly, this is old news. I first saw it described in May 1998:

http://lists.insecure.org/lists/bugtraq/1998/May /0 182.html

Thats 5 years ago.

Mads Bondo Dydensborg

P.S. There are no spaces in that url, I think /. is doing something weird here.

Re:Old and not related to gamespy by Anonymous Coward · 2003-01-20 07:47 · Score: 0

This is a case where the problem is still being produced in new and upcoming games, so i'm glad its being addressed.

Re:Games don't support GameSpy by MrBooga · 2003-01-20 10:40 · Score: 1

GameSpy supplies the game status code for the majority of on-line game servers. They sell an SDK which you can bake into you game to make it GameSpy compatible. Since many of the game servers are using this SDK, they're all capable of hosting a third-party DOS or DDOS. If they fix their SDK, then many games could release server patches and greatly reduce the problem. (so, this is very much a GameSpy issue, but the biggest game,
Half-Life, does not use GameSpy SDK)

The best fix is a short-lived-cookie based protocol. But this will double the number of packets needed to get game server status information, and require client patches. A server-side throttling fix is best we can really hope for.

Last Post! by alpg · 2003-02-02 15:09 · Score: 0

An idea is an eye given by God for the seeing of God. Some of these eyes
we cannot bear to look out of, we blind them as quickly as possible.
-- Russell Hoban, "Pilgermann"

- this post brought to you by the Automated Last Post Generator...

Slashdot Mirror

Multi-vendor Game Server (GameSpy) DDoS Attack

188 comments