[NEWS] Gamespy CD-Key Validation System "CD-Key In Use" DoS

• Previous message: SecuriTeam: "[EXPL] Avoiding Stack Protections Shellcode Example"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: list@securiteam.com
Date: 5 May 2005 19:53:30 +0200

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

  Gamespy CD-Key Validation System "CD-Key In Use" DoS
------------------------------------------------------------------------

SUMMARY

"The <http://www.gamespy.net/> 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."

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 rather only random text
strings and the MD5 hashes needed to verify the original CD-key and the
correctness of the packet. An 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 making the real owner of the CD-key to become unable to play
online.

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.

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

How to Exploit:
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>
http://aluigi.altervista.org/poc/gore148gskeyinuse.zip

Requirements for the second method:
 - A normal game server
 - GsHsniff for capturing the authorization requests
 - The proof-of-concept to replicate the requests in ANY moment you want

The explanations are available in the following section.

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

 - GsHsniff: <http://aluigi.altervista.org/papers/gshsniff.zip>
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>
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 favorite 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\0123456789abcdef...abcdef01234567
\ip\123456\skey\1234\auth\\pid\999\ch\253h2\resp\abcde...def
..
(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>
http://aluigi.altervista.org/papers/gskeycheck.zip

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

ADDITIONAL INFORMATION

The information has been provided by <mailto:aluigi@autistici.org> Luigi
Auriemma .

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

• Previous message: SecuriTeam: "[EXPL] Avoiding Stack Protections Shellcode Example"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]