('binary' encoding is not supported, stored as-is) ######################################################################## 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: mkristovichat_private 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 mkristovichat_private Geoff Shively, CHO PivX Solutions, LLC gshivelyat_private ______________________________________________________________________
This archive was generated by hypermail 2b30 : Tue Jan 21 2003 - 18:25:35 PST