Gamespy cd-key validation system: "Cd-key in use" DoS versus many games

2005-05-11T00:00:00
ID SECURITYVULNS:DOC:8592
Type securityvulns
Reporter Securityvulns
Modified 2005-05-11T00:00:00

Description

                         Luigi Auriemma

Application: Gamespy cd-key validation system http://www.gamespy.net Games: The amount of games that use this system is really huge, a small list (maintained by me) is available here: http://aluigi.altervista.org/papers/gshlist.txt An official list of games that use the Gamespy stuff (so not only the cd-keys) is available here: http://www.gamespy.net/partners/ Versions: each game must implement the future fixed SDK with a patch, anyway is impossible for me to list all the vulnerable games versions (in this moment ALL) Bug: Denial of Service, players with valid cd-keys cannot play online due to the "Cd-key in use" error message Exploitation: remote, versus clients with valid cd-keys Date: 04 May 2005 Author: Luigi Auriemma e-mail: aluigi@autistici.org web: http://aluigi.altervista.org

1) Introduction 2) Bug in short 3) Bug details 4) An example of real life 5) What an attacker needs 6) The Code 7) Fix

=============== 1) Introduction ===============

The Gamespy cd-key validation system is a toolkit used by a HUGE number of multiplayer games and is needed to allow the verification of the cd-keys used by the players when they want to join an online game server.

Some of the most famous and played games that use this toolkit are Halo, Battlefield 1942 and Vietnam, Men of Valor, Painkiller, Star Wars Battlefront, Star Wars Republic Commando, Tribes: Vengeance and many others between those listed here:

http://www.gamespy.net/partners/

=============== 2) Bug in short ===============

An attacker can sniff all the valid cd-key authorizations sent from his server to the Gamespy master server when a player joins his match. These queries do NOT contain the plain-text cd-key but only some random text strings and the MD5 hashes needed to verify the original cd-key and the correctness of the packet.

Then the attacker can send the same captured queries to the master server emulating what a common server does. This mechanism allows the real cd-key to be considered in use in the server of the attacker so when the real owner of the cd-key tries to play online its client is kicked from any game server he wants to join.

Note that this implementation bug does NOT allow the attackers to stole or reuse the valid cd-keys but only to block them for all the time they want.

============== 3) Bug details ==============

The Gamespy cd-key validation system is a server-side mechanism for verifying if the cd-keys used by the clients are valid or not. Server-side means that all the authorization is handled by the game server, it is the only one that contacts the master server. The part of the client in this mechanism is limited to the passing of its cd-key hash to the game server.

With client is meant the game client so the users/gamers, with server is identified a game server hosted by any user while the master server is the central server owned by Gamespy that contains the archive of valid cd-keys and their MD5 hashes. I think these terms are well known by anyone but I prefer to be sure.

The step-by-step for validating a cd-key through the Gamespy system is the following: - client joins the server - server generates a random text string and sends it to the client - client composes a string of 72 chars using also the string received from the server: http://aluigi.altervista.org/papers/gskey-auth.txt - server sends to the master server its string plus the response received from the client - the master server replies reporting if the client cd-key is valid or not (and why not) - if the valid cd-key has been previously authorized from another server the master server first tries to contact this one to know if the player with that cd-key is still playing (\ison\). If a negative (\uoff\) or no reply is received the cd-key is considered free and the new user is authorized

The flaw is clear: what happens if the server that has authorized the cd-key for first continues to report that the player is playing on it forever? The answer is simple, the real player with the valid cd-key will be no longer able to play online because his cd-key is in use in that server.

Creating this situation is very simple, a normal game server can capture the authorization requests it sends to the Gamespy master server when a player joins and then it can reuse the same identical requests forcing the real cd-keys to enter in the "Cd-key in use" state (exist 2 ways to exploit the bug, read the section 5).

An authorization request is composed by the following parameters:

\auth\ = identifies the type of query, authorization \pid\ = the Gamespy product ID of the played game: http://aluigi.altervista.org/papers/gspids.txt \ch\ = what I have called server token, it is the text string randomly generated by the server and sent to the client \resp\ = contains the MD5 hash of the client cd-key, the client token (another random string but generated by the client) and a MD5 hash used to verify the correctness of the request (so nobody can modify the other values) \ip\ = IP address of the client in decimal format \skey\ = a random number used to track the request and the subsequent reply

The pid, the ch and the resp are all the stuff that the attacker needs.

When the real player joins a server the master server receives the authorization request, checks if the cd-key is valid and then contacts the fake server with a query similar to the following:

\ison\\cd\0123456789abcdef0123456789abcdef\skey\1234

And the fake server must simply reply with:

\uon\\skey\1234

The cd-key is still in use in the fake server and the real player will be booted quickly from the server he wants to join with the "Cd-key in use" error message.

========================== 4) An example of real life ==========================

A guy, that we will call Luigi, has just bought the game Painkiller in a big super market of his town (in reality he likes racing games but this is only an example).

He is very happy to have bought this game because it's cool and very splatter and moreover because is possible to play online where this FPS finds his natural habitat.

Luigi arrives at home, installs the game, inserts his cd-key, applies the latest patch found on a recent game magazine and connects to Internet, he is really anxious to frag other users.

He finds a server with an interesting name and with 8 players in it and decides to join and plays on it for over one hour conquering some victories and many defeats.

Now he is tired and decides to reconnect later but he has a bad surprise: he receives a "Cd-key in use" error message everytime he tries to join any online server.

He doesn't understand why that happens, he thinks someone has stolen his cd-key so after many troubles, time lost, mails to the game support and posts on many forums with no results he abandons the game and decides to give up.

========================= 5) What an attacker needs =========================

An attacker has two ways to exploit this bug, and in both is needed to have a public game server available on Internet.

Requirements for the first method

  • a game server using a modified executable that avoids the sending of the \disc\ command and with \uoff\ replaced by \uon\.

The result is that a player with a valid cd-key joins the attacker server but his cd-key remains in use also when he left the match. Modifying the executable is very simple but remember that the commands are not stored in plain-text in the code but are easily built at runtime (something like buff[0]='\\'; buff[1]='d'; buff[2]='i'; buff[3]='s'; buff[4]='c'; ... the pattern is similar to all the games that use this toolkit). For example in some minutes and with the substitution of only 3 bytes I have modified with success the executable of Gore 1.48:

http://aluigi.altervista.org/poc/gore148gskeyinuse.zip

Requirements for the second method

  • a normal game server
  • GsHsniff for capturing the authorization requests
  • my proof-of-concept to replicate the requests in ANY moment you want

The explanations are available in the following section.

=========== 6) The Code ===========

The proof-of-concept (for the second exploitation method) is composed by two tools:

  • GsHsniff http://aluigi.altervista.org/papers/gshsniff.zip

a sniffer able to capture all the encoded queries sent and received from the master server

  • Gamespy cd-key validation: "Cd-key in use" DoS http://aluigi.altervista.org/poc/gskeyinuse.zip

the real proof-of-concept, it reads all the autorization requests (in plain-text) contained in a file and sends them to the master server. Then it enters in a listening mode so can report that the cd-keys of the players are still and ever in use.

Practical usage

Put all the authorization requests collected with GsHsniff in a text file like keys.txt. This is very simple to do, you need only to launch GsHsniff, run a dedicated server of your favourite game and then join in it (the game must use the Gamespy cd-key validation toolkit naturally). When the request is captured close both the server and the client.

The file keys.txt must look similar to the following:

\auth\\pid\123\ch\aBcDeFg\resp\0123456789abcdef0123456789abcdef0123456789ab cdef0123456789abcdef01234567\ip\123456\skey\1234 \auth\\pid\999\ch\253h2\resp\abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcd efabcdefabcdefabcdefabcdef ... (one \auth\ request is enough, one for each cd-key)

Launch gskeyinuse specifying the name of the text file with the collected requests and the local port to bind:

gskeyinuse keys.txt 7777

Both the tools are very verbose so any detail is ever visible and GsHsniff is useful to see in real-time what I have tried to explained with my words (moreover using its options).

After having launched the proof-of-concept you can verify that your cd-key is in use joining an online game server or using the tool I have written just for this purpose:

http://aluigi.altervista.org/papers/gskeycheck.zip

If you receive a "Cd-key in use" error means your game is vulnerable.

====== 7) Fix ======

Gamespy has been contacted and is working for a solution.

FYI, naturally Gamespy was aware of this problem from many years since it was visible during the engineering of the cd-key validation system, but this is another story...

The fix will require a new version of the SDK so the games must implement it in their next patches. Traduced: many games will remain vulnerable for long time and many others forever because no longer supported.

Naturally the players with valid cd-keys can avoid the "Cd-key in use" problem with 2 methods:

  • play only on trusted servers and verify ever their IP addresses because an attacker can set up a server with the same name and details of another one

  • if you think that someone is keeping your cd-key in use, wait if the situation returns normal within some hours and then contact Gamespy since they are the only to know the IP address of the attacker server

As already said many games will be never patched so keep these rules in mind.


Luigi Auriemma http://aluigi.altervista.org