Message-ID: <20050504190340.5638b793.aluigi@autistici.org>
Date: Wed May  4 18:02:34 2005
From: aluigi at autistici.org (Luigi Auriemma)
Subject: Gamespy cd-key validation system: "Cd-key in use"
 DoS versus many games


#######################################################################

                             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@...istici.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

Powered by blists - more mailing lists