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

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:[email protected]> 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: [email protected] 
In order to subscribe to the mailing list, simply forward this email to: [email protected] 


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

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.