Mike Kristovich
22/01/03, 03:24
################################################## ######################
Mike Kristovich, PivX Security Advisory MK#001
Date: November 26, 2002
Released: January 16, 2002
Application: Battlefield 1942 (Server and Dedicated Server)
America's Army
Unreal Tournament 2003
and more.. see section 2.
Version: All up to current.
Bug: Server status port replies to spoofed UDP packets
with large amount of data.
Risk: High, BF1942 servers flooded or used as flooders, DDoS risk
Author: Mike Kristovich, Security Researcher, PivX Solutions, LLC
e-mail: mkristovich@pivx.com
Web: http://www.PivX.com/kristovich
################################################## ######################
Sections:
1) Introduction
2) Bug
3) Proof of concept code.
4) Fix
5) Philosophy
6) Closing comments..
7) Related Documents and Advisories
8) DDoS Related Quotes
9) Contact
__________________________________________________ ____________________
1) Introduction
This document is based on Battlefield 1942's query responses, but
this vulnerability exists in many games. As a basic rule of thumb,
if it supports gamespy (http://www.gamespy.com), it will likely be
vulnerable.
The following games are vulnerable to the same type of attack, and
most use the same general query commands (excluding Quake, Quake 2,
Return to Castle Wolfenstein, and a couple others). The other query
commands can be found in the source of a free program called "Server
Query" (http://www.ServerQuery.com). The general rule of thumb is:
If its supported by GameSpy and Server Query, its vulnerable.
Affected Games
--------------
Quake Quake 2 Q3: Arena & Team Arena
Kingpin Half-Life Counter-Strike
Sin Soldier of Fortune Daikatana
Unreal Tourn. Quakeworld Unreal
Rune Gore Tribes
Tribes 2 Serious Sam Serious Sam 2
C&C: Renegade Global Operations Jedi Knight 2
Battlefield 1942
America's Army
Unreal Tournament 2003
Return to Castle Wolfenstein
Medal of Honour: Allied Assault
SoF2: Double Helix
SoF2: Double Helix Demo
Alien vs Predator 2
NeverWinter Nights
V8 Supercar Challenge
---------------------------------
The usage example for Battlefield 1942 follows..
The risk for this vulnerability seems to be worse on a game such
as Battlefield 1942 due to its ability for to support 64 player
servers.
Battlefield 1942 servers listen on UDP port 23000, awaiting commands:
i.e. '\status\' '\players\' '\packets\' '\echo\' '\rules\', and more.
The server uses a protocol very similar to UT2003 and America's Army,
and many other GameSpy* supported games.
* Gamespy is a popular program that allows game clients to find and
connect to game servers.
BF1942 allows you to combine requests:
i.e. '\status\players\packets\rules\'
When a request like the example above is sent, it uses approximately
30 bytes, not including UDP overhead. The resulting response
can be anywhere from as low as 6000 - 7000, to as high as 11,000+
bytes. Using an example of 30 bytes:11,799 bytes, we get a ratio of
1:393. Basically, for every 1 byte we've sent, 393 are returned (in this
particular example, which comes from a server housing 41 players)..
Results will vary. A server which holds 64 players could potentially
respond with well over 18,000 bytes.
A server housing 31 players, in our test, responded with 9,583 bytes
for a single 30 byte request.
Side note, one single UDP request using the query line in our POC code
responds with 10 seperate responses (due to packet size limitations.)
This also means, if the victim port is unreachable, the victim will
respond to the data with 10 ICMP Unreachable responses.
__________________________________________________ ____________________
2) Bug
UDP is a connectionless protocol of which the source ip and port can
easily be spoofed. If you've read the introduction, you can probably
see where I'm going with this.
The BF1942 status port will reply an amazing amount of requests,
and although I have only personally tested this to 50 kbytes/sec, I
dont see any reason why you couldn't go even higher.
When these requests are received, the reply is sent to the source host
which, in this case, we have spoofed. This causes a huge packet flood
to your victim, therefore you now have your DoS.
When tested, a single upstream of 4 k/s to the BF1942 server yielded
over 550 k/s being sent to the victim host. When the victim's host
receives these packets on a UDP port which is open (commonly found
to be 135 (MS/DCE RPC), 53 (DNS), and so on), the downstream to that
connection will be flooded. If you sent to an unreachable port on
the victim's host, the victim's stack will respond with "Unreachable"
responses which will also flood their upstream.
A personal firewall will such as ZoneAlarm will not prevent this
DoS, as it is simply a flood of information being sent directly to
the victim's computer. To stop this DoS from reaching the victim,
the port you specify would have to be blocked before reaching their
system. Ports you would find particularly useless would be ones that
are commonly blocked by ISPs before reaching the customers:
(139/NetBIOS, and so on). A firewall will only prevent the victim
from responding with ICMP Unreachable packets.
Notes on bug
-------------
* Packets can be sent steadily, no wait time needed for refresh.
Further information, discussion..
---------------------------------
This is an attack that can easily flood any system slower than the
Battlefield 1942 server, and do it anonymously because the UDP
packet source is spoofed to that of the victim. This is very similar
to the "smurf" attack that was used in the late 20th century. =)
The attack does not only affect the bandwidth of the host and the
victim, but it also tends to eat up a nice chunk of memory and CPU
power on the server.
This low amount of required upstream would allow a simple modem user
to send a hefty DoS to a T1 or higher.
Due to the fact that Battlefield 1942 servers tend to require a
lot of bandwidth to operate, you are very likely to find that nearly
any server will have more than enough bandwidth to handle the task.
EA has many of their servers hosted on OC3 lines.
In many ways, this exceeds the severity of the smurf attack method.
Example theory of risk:
T1 (1.54 mbps) FULL DoS:
1 server needed @ ~220 k/s or more (a 20 player server will do).
1 - 2 k/s* upstream needed from attacker (~14.4 baud modem)
A single user dialed up at 14,400 bps can topple a T1.
A single dial-up at 56k (31.2kbit up) could DoS 2 T1s at a time.
* You must account for UDP overhead (IP Header, UDP Header)
__________________________________________________ ____________________
3) Proof-of-concept code
Proof of concept code is to show usage of this vulnurability.
Please use it with caution.
http://www.pivx.com/kristovich/poc/bf1942dos.c
__________________________________________________ ____________________
4) Fix
No fix is currently available from EA.
No fix is currently available from others.
No fix currently, but a fix is planned from GameSpy.
Electronic Arts was informed, but did not respond.
(11/20/2002 - 1/13/2002)
__________________________________________________ ____________________
5) Philosophy
Full disclosure is needed to ensure that the bug can be fixed
or reviewed before it gets into the hands of the wrong person.
Hopefully, the POC code for this will ensure that people will
know the full effects of an attack of this sort.
__________________________________________________ ____________________
6) Closing comments..
While UDP spoofing is near extinction due to network providers
finally deciding to block it, this is still a threat.
The POC code provided allows you to specify how many kilobytes/sec
you would like to use when sending requests. This includes overhead.
Coffee consumed during research: 32 cups.
As far as risk assessment, think about this: Global nameservers.
Gamespy.
__________________________________________________ ____________________
7) Related Documents and Advisories
Modern Day UDP Spoofing:
http://www.pivx.com/kristovich/papers/modernudp.txt
Server Query
http://www.ServerQuery.com
The Distributed Reflection DoS Attack
http://grc.com/dos/drdos.htm
0x00.org
http://0x00.org/random/Halflife/QueryingGameServers.txt
Application-Level Reflection Attacks
by Tom Vogt
__________________________________________________ ____________________
8) DDoS Related Quotes
There is an article in a dalnet newsgroup in which Jim-mm (@dal.net)
makes many good points about DDoS, and how these attacks threaten
everyone. The letter he has written is conserning current DDoS
attacks that are making DALNet unaccessable.
-- Start Quote --
It is no exageration to say that these continuing attacks threaten the
existance of DALnet. Many of our hosts are being seriously impacted by
what are very large (multi-Gb/s) attacks are are understandably
considering whether or not they can continue to support DALnet.
We at DALnet have repeatedly begged various providers for assistance to
curb these problems however we have had limited success. I have seen a
single abuser infect over 2000 machines in a day, while still others
exploit ISP stupidity by compromising DSL/cable routers which have no
passwords, weak or default passwords or insecure telnet ports open to
the internet. Even when notifed of this stupidity ISP's either refuse to
act or act so slowly they may as well be doing nothing. Then you have
insecure Win2k boxes of which litterally thousands attack us every day,
not to mention the myriad of users who click a URL and get infected with
something through a browser weakness they really should have patched
months ago.
We are a single group of volunteers. We cannot secure the entire
internet on our own, ISP's and service providers MUST start accepting
responsibility for the machines they allow to connect to the internet at
large or the internet as we know it will cease to exist. Beleive me,
it's a short step from DoS'ing an IRC network to shutting down a major
commercial site, the root nameservers or even a major peering point. In
a world where even the most clueless abuser can gather well over a Gb/s
of compromised bandwidth in less than 12 hours that's not just possible,
it's inevitable.
What can service providers do... well, here's a few ideas :
- Block telenet, netbios and socks proxy ports at the border.
- Make running a personal firewall a condition of service and provide
support to users to help them set it up securely.
- Develop some kind of collaberative tracing system so it's possible to
trace spoofed packets to source _easily_.
- Enforce egress filtering to eliminate the possibility of launching
spoofed source attacks from their networks.
- Enforce their terms of service by disconnecting users who are involved
in internet attacks. Far too many don't.
- STOP using routers that are insecure. Pester the manufactureres of
said routers to fix the damn things, after all the ISP's are their major
clients!
Would it help, yes. Will it ever happen, I doubt it, well not until the
attackers start pounding the crap out of one ISP after another that is,
then perhaps they'll pay attention. **
-- End Quote --
** PivX Solutions does not condone attacking ISPs.
__________________________________________________ ____________________
9) Contact
Any questions, comments, complaints:
Mike Kristovich, Security Researcher
PivX Solutions, LLC
mkristovich@pivx.com
Geoff Shively, CHO
PivX Solutions, LLC
gshively@pivx.com
__________________________________________________ ____________________
Mike Kristovich, PivX Security Advisory MK#001
Date: November 26, 2002
Released: January 16, 2002
Application: Battlefield 1942 (Server and Dedicated Server)
America's Army
Unreal Tournament 2003
and more.. see section 2.
Version: All up to current.
Bug: Server status port replies to spoofed UDP packets
with large amount of data.
Risk: High, BF1942 servers flooded or used as flooders, DDoS risk
Author: Mike Kristovich, Security Researcher, PivX Solutions, LLC
e-mail: mkristovich@pivx.com
Web: http://www.PivX.com/kristovich
################################################## ######################
Sections:
1) Introduction
2) Bug
3) Proof of concept code.
4) Fix
5) Philosophy
6) Closing comments..
7) Related Documents and Advisories
8) DDoS Related Quotes
9) Contact
__________________________________________________ ____________________
1) Introduction
This document is based on Battlefield 1942's query responses, but
this vulnerability exists in many games. As a basic rule of thumb,
if it supports gamespy (http://www.gamespy.com), it will likely be
vulnerable.
The following games are vulnerable to the same type of attack, and
most use the same general query commands (excluding Quake, Quake 2,
Return to Castle Wolfenstein, and a couple others). The other query
commands can be found in the source of a free program called "Server
Query" (http://www.ServerQuery.com). The general rule of thumb is:
If its supported by GameSpy and Server Query, its vulnerable.
Affected Games
--------------
Quake Quake 2 Q3: Arena & Team Arena
Kingpin Half-Life Counter-Strike
Sin Soldier of Fortune Daikatana
Unreal Tourn. Quakeworld Unreal
Rune Gore Tribes
Tribes 2 Serious Sam Serious Sam 2
C&C: Renegade Global Operations Jedi Knight 2
Battlefield 1942
America's Army
Unreal Tournament 2003
Return to Castle Wolfenstein
Medal of Honour: Allied Assault
SoF2: Double Helix
SoF2: Double Helix Demo
Alien vs Predator 2
NeverWinter Nights
V8 Supercar Challenge
---------------------------------
The usage example for Battlefield 1942 follows..
The risk for this vulnerability seems to be worse on a game such
as Battlefield 1942 due to its ability for to support 64 player
servers.
Battlefield 1942 servers listen on UDP port 23000, awaiting commands:
i.e. '\status\' '\players\' '\packets\' '\echo\' '\rules\', and more.
The server uses a protocol very similar to UT2003 and America's Army,
and many other GameSpy* supported games.
* Gamespy is a popular program that allows game clients to find and
connect to game servers.
BF1942 allows you to combine requests:
i.e. '\status\players\packets\rules\'
When a request like the example above is sent, it uses approximately
30 bytes, not including UDP overhead. The resulting response
can be anywhere from as low as 6000 - 7000, to as high as 11,000+
bytes. Using an example of 30 bytes:11,799 bytes, we get a ratio of
1:393. Basically, for every 1 byte we've sent, 393 are returned (in this
particular example, which comes from a server housing 41 players)..
Results will vary. A server which holds 64 players could potentially
respond with well over 18,000 bytes.
A server housing 31 players, in our test, responded with 9,583 bytes
for a single 30 byte request.
Side note, one single UDP request using the query line in our POC code
responds with 10 seperate responses (due to packet size limitations.)
This also means, if the victim port is unreachable, the victim will
respond to the data with 10 ICMP Unreachable responses.
__________________________________________________ ____________________
2) Bug
UDP is a connectionless protocol of which the source ip and port can
easily be spoofed. If you've read the introduction, you can probably
see where I'm going with this.
The BF1942 status port will reply an amazing amount of requests,
and although I have only personally tested this to 50 kbytes/sec, I
dont see any reason why you couldn't go even higher.
When these requests are received, the reply is sent to the source host
which, in this case, we have spoofed. This causes a huge packet flood
to your victim, therefore you now have your DoS.
When tested, a single upstream of 4 k/s to the BF1942 server yielded
over 550 k/s being sent to the victim host. When the victim's host
receives these packets on a UDP port which is open (commonly found
to be 135 (MS/DCE RPC), 53 (DNS), and so on), the downstream to that
connection will be flooded. If you sent to an unreachable port on
the victim's host, the victim's stack will respond with "Unreachable"
responses which will also flood their upstream.
A personal firewall will such as ZoneAlarm will not prevent this
DoS, as it is simply a flood of information being sent directly to
the victim's computer. To stop this DoS from reaching the victim,
the port you specify would have to be blocked before reaching their
system. Ports you would find particularly useless would be ones that
are commonly blocked by ISPs before reaching the customers:
(139/NetBIOS, and so on). A firewall will only prevent the victim
from responding with ICMP Unreachable packets.
Notes on bug
-------------
* Packets can be sent steadily, no wait time needed for refresh.
Further information, discussion..
---------------------------------
This is an attack that can easily flood any system slower than the
Battlefield 1942 server, and do it anonymously because the UDP
packet source is spoofed to that of the victim. This is very similar
to the "smurf" attack that was used in the late 20th century. =)
The attack does not only affect the bandwidth of the host and the
victim, but it also tends to eat up a nice chunk of memory and CPU
power on the server.
This low amount of required upstream would allow a simple modem user
to send a hefty DoS to a T1 or higher.
Due to the fact that Battlefield 1942 servers tend to require a
lot of bandwidth to operate, you are very likely to find that nearly
any server will have more than enough bandwidth to handle the task.
EA has many of their servers hosted on OC3 lines.
In many ways, this exceeds the severity of the smurf attack method.
Example theory of risk:
T1 (1.54 mbps) FULL DoS:
1 server needed @ ~220 k/s or more (a 20 player server will do).
1 - 2 k/s* upstream needed from attacker (~14.4 baud modem)
A single user dialed up at 14,400 bps can topple a T1.
A single dial-up at 56k (31.2kbit up) could DoS 2 T1s at a time.
* You must account for UDP overhead (IP Header, UDP Header)
__________________________________________________ ____________________
3) Proof-of-concept code
Proof of concept code is to show usage of this vulnurability.
Please use it with caution.
http://www.pivx.com/kristovich/poc/bf1942dos.c
__________________________________________________ ____________________
4) Fix
No fix is currently available from EA.
No fix is currently available from others.
No fix currently, but a fix is planned from GameSpy.
Electronic Arts was informed, but did not respond.
(11/20/2002 - 1/13/2002)
__________________________________________________ ____________________
5) Philosophy
Full disclosure is needed to ensure that the bug can be fixed
or reviewed before it gets into the hands of the wrong person.
Hopefully, the POC code for this will ensure that people will
know the full effects of an attack of this sort.
__________________________________________________ ____________________
6) Closing comments..
While UDP spoofing is near extinction due to network providers
finally deciding to block it, this is still a threat.
The POC code provided allows you to specify how many kilobytes/sec
you would like to use when sending requests. This includes overhead.
Coffee consumed during research: 32 cups.
As far as risk assessment, think about this: Global nameservers.
Gamespy.
__________________________________________________ ____________________
7) Related Documents and Advisories
Modern Day UDP Spoofing:
http://www.pivx.com/kristovich/papers/modernudp.txt
Server Query
http://www.ServerQuery.com
The Distributed Reflection DoS Attack
http://grc.com/dos/drdos.htm
0x00.org
http://0x00.org/random/Halflife/QueryingGameServers.txt
Application-Level Reflection Attacks
by Tom Vogt
__________________________________________________ ____________________
8) DDoS Related Quotes
There is an article in a dalnet newsgroup in which Jim-mm (@dal.net)
makes many good points about DDoS, and how these attacks threaten
everyone. The letter he has written is conserning current DDoS
attacks that are making DALNet unaccessable.
-- Start Quote --
It is no exageration to say that these continuing attacks threaten the
existance of DALnet. Many of our hosts are being seriously impacted by
what are very large (multi-Gb/s) attacks are are understandably
considering whether or not they can continue to support DALnet.
We at DALnet have repeatedly begged various providers for assistance to
curb these problems however we have had limited success. I have seen a
single abuser infect over 2000 machines in a day, while still others
exploit ISP stupidity by compromising DSL/cable routers which have no
passwords, weak or default passwords or insecure telnet ports open to
the internet. Even when notifed of this stupidity ISP's either refuse to
act or act so slowly they may as well be doing nothing. Then you have
insecure Win2k boxes of which litterally thousands attack us every day,
not to mention the myriad of users who click a URL and get infected with
something through a browser weakness they really should have patched
months ago.
We are a single group of volunteers. We cannot secure the entire
internet on our own, ISP's and service providers MUST start accepting
responsibility for the machines they allow to connect to the internet at
large or the internet as we know it will cease to exist. Beleive me,
it's a short step from DoS'ing an IRC network to shutting down a major
commercial site, the root nameservers or even a major peering point. In
a world where even the most clueless abuser can gather well over a Gb/s
of compromised bandwidth in less than 12 hours that's not just possible,
it's inevitable.
What can service providers do... well, here's a few ideas :
- Block telenet, netbios and socks proxy ports at the border.
- Make running a personal firewall a condition of service and provide
support to users to help them set it up securely.
- Develop some kind of collaberative tracing system so it's possible to
trace spoofed packets to source _easily_.
- Enforce egress filtering to eliminate the possibility of launching
spoofed source attacks from their networks.
- Enforce their terms of service by disconnecting users who are involved
in internet attacks. Far too many don't.
- STOP using routers that are insecure. Pester the manufactureres of
said routers to fix the damn things, after all the ISP's are their major
clients!
Would it help, yes. Will it ever happen, I doubt it, well not until the
attackers start pounding the crap out of one ISP after another that is,
then perhaps they'll pay attention. **
-- End Quote --
** PivX Solutions does not condone attacking ISPs.
__________________________________________________ ____________________
9) Contact
Any questions, comments, complaints:
Mike Kristovich, Security Researcher
PivX Solutions, LLC
mkristovich@pivx.com
Geoff Shively, CHO
PivX Solutions, LLC
gshively@pivx.com
__________________________________________________ ____________________