####################################################################### Luigi Auriemma Applicazione: Sistema di verifica delle cd-key di Gamespy http://www.gamespy.net Giochi: La quantita' di giochi che utilizza questo sistema e' davvero enorme ed una piccola lista (mantenuta da me) e' disponibile qui: http://aluigi.org/papers/gshlist.txt Una lista ufficiale di giochi che utilizzano il materiale di Gamespy (quindi non solo le cd-keys) e' invece reperibile qui: http://www.gamespy.net/partners/ Versioni: ogni gioco deve implementare il futuro SDK corretto con una patch, inoltre per me e' impossibile elencare tutte le versioni dei giochi vulnerabili (al momento TUTTE) Bug: Denial of Service, i giocatori con le cd-key valide non possono giocare online a causa del messaggio di errore "Cd-key in use" Exploitation: remoto, contro i client con cd-key valide Data: 04 May 2005 Autore: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org ####################################################################### 1) Introduzione 2) Bug in breve 3) Bug in dettaglio 4) Un esempio di vita reale 5) Di cosa necessita un attacker 6) The Code 7) Fix ####################################################################### =============== 1) Introduction =============== Il sistema di verifica delle cd-key di Gamespy e' un toolkit utilizzato da un numero ENORME di giochi multiplayer ed e' necessario per la verifica delle cd-key utilizzate dai giocatori quando entrano in un server online. Alcuni dei giochi piu' famosi e giocati che utilizzano tale toolkit sono Halo, Battlefield 1942 e Vietnam, Men of Valor, Painkiller, Star Wars Battlefront, Star Wars Republic Commando, Tribes: Vengeance e molti altri tra quelli elencati qui: http://www.gamespy.net/partners/ ####################################################################### =============== 2) Bug in breve =============== Un attacker puo' sniffare tutte le autorizzazioni per le cd-key valide inviate dal proprio server al master server di Gamespy quando un giocatore entra nella partita da lui ospitata. Queste richieste NON contengono le cd-key in chiaro ma solo alcune stringhe di testo casuali e hash MD5 necessari per la verifica della cd-key originale e per la correttezza del pacchetto. Dopo di cio' l'attacker puo' inviare le stesse identiche richieste che ha catturato al master server emulando le operazioni compiute da un normale server. Questo meccanismo permette alla cd-key reale di essere considerata in uso sul server dell'attacker cosi' quando il reale possessore di tale cd-key prova a giocare online il suo client viene sbattuto fuori da qualsiasi server di gioco nel quale lui voglia entrare. Da notare che questo bug di implementazione NON permette agli attacker di rubare o riutilizzare le cd-key valide ma solo di bloccarle per quanto tempo si vuole. ####################################################################### =================== 3) Bug in dettaglio =================== Il sistema di verifica delle cd-key di Gamespy e' un meccanismo solo server-side per verificare appunto che le cd-key utilizzate dai clients siano valide. Server-side significa che tutta l'autorizzazione e' gestita dal server di gioco, il quale e' l'unico a contattare il master server. La parte del client in tale meccanismo e' limitata al passaggio del hash della propria cd-key al server. Con client si intende il client di gioco quindi gli utenti/giocatori, con server si identifica un server di gioco hostato da qualsiasi utente mentre il master server e' il server centrale in possesso di Gamespy che contiene l'archivio di tutte le cd-key valide ed i loro corrispettivi hash MD5. Penso che questi termi siano di uso comune ma e' meglio esserne sicuri. Il procedimento passo-passo per verificare una cd-key attraverso il sistema di Gamespy e' il seguente: - il client entra nel server - il server genera una stringa di testo casuale e la invia al client - il client crea una stringa di 72 caratteri basandosi anche su quanto ricevuto dal server: http://aluigi.org/papers/gskey-auth.txt - il server invia al master server la propria stringa piu' il responso ricevuto dal client - il master server comunica al server se la cd-key del client e' valida o no (e per quale motivo) - se la cd-key valida e' stata autorizzata precedentemente da un altro server, il master server prima contatta quest'ultimo in modo da verificare se il giocatore con tale cd-key sta' ancora giocando (\ison\). Se non viene ricevuta alcuna risposta od una negativa (\uoff\) la cd-key viene considerata libera e l'utente e' autorizzato Il problema e' chiaro: cosa succede se il server che ha autorizzato la cd-key per primo continua a dire per sempre che il client sta' ancora giocando? La risposta e' semplice, il vero giocatore con la cd-key valida non sara' piu' in grado di giocare online in quanto la sua cd-key e' ancora in uso su quel server. Creare una situazione simile e' molto semplice, un normale server di gioco puo' catturare le richieste di autorizzazione che invia al master server di Gamespy quando un giocatore entra per poi riutilizzarle facendo si' che la cd-key entri nello stato di "Cd-key in use". Una richiesta di autorizzazione e' composta dai seguenti parametri: \auth\ = identifica il tipo di richiesta, autorizzazione appunto \pid\ = il Gamespy product ID del gioco: http://aluigi.org/papers/gspids.txt \ch\ = cio' che io ho chiamato server token, ossia la stringa di testo generata dal server ed inviata al client \resp\ = contiene l'hash MD5 della cd-key del client, il client token (un'altra stringa casuale ma stavolta generata dal client) ed un hash MD5 utilizzato per verificare la correttezza dalla richiesta (in modo che nessuno possa modificare gli altri parametri) \ip\ = indirizzo IP del client in formato decimale \skey\ = un numero casuale utilizzato per tenere traccia della successiva risposta Il pid, il ch ed il resp sono tutto cio' di cui l'attacker necessita. Quando il giocatore reale entra in un server il master server riceve la richiesta di autorizzazione, verifica che la cd-key sia valida e poi contatta il falso server con una query simile alla seguente: \ison\\cd\0123456789abcdef0123456789abcdef\skey\1234 Ed il server fasullo in mano all'attacker deve rispondere con: \uon\\skey\1234 La cd-key quindi e' ancora in uso nel server dell'attacker ed il giocatore verra' espulso velocemente dal server nel quale voleva entrare con il messaggio di errore "Cd-key in use". ####################################################################### =========================== 4) Un esempio di vita reale =========================== Un ragazzo, che chiameremo Luigi, ha appena comprato il gioco Painkiler in un grande supermercato della sua zona (in realta' lui preferisce i giochi di corse ma questo e' soltanto un esempio). E' davvero contento di questo gioco perche' oltre ad essere mozzafiato e decisamente splatter e' anche possibile giocare online ove tale FPS ritrova il suo habitat naturale. Luigi arriva a casa, installa il gioco, inserisce la cd-key, applica l'ultima patch trovata un una rivista di videogiochi di questo mese e si connette immediatamente ad Internet in quanto e' davvero impaziente di fraggare gli altri utenti. Trova un server con un nome abbastanza accattivante e con 8 giocatori quindi decide di entrare. Gioca su questo server per oltre un'ora conquistando alcune vittorie e molte sconfitte. Per via della stanchezza decide di riconnettersi piu' tardi ma riceve una brutta sorpresa: in qualsiasi server lui cerchi di entrare riceve sempre il mesaggio di errore "Cd-key in use". Non ha la minima idea di cosa stia succedendo, inizialmente pensa sia per colpa di qualcuno che abbia rubato la sua cd-key ma sa che non e' possibile, cosi' dopo diversi fastidi, tempo perso, mails all'assistenza del gioco e posts su diversi forum senza risultati decide di abbandonare il gioco e rinunciare. ####################################################################### ================================ 5) Di cosa necessita un attacker ================================ Un attacker ha due vie per sfruttare questo bug, ed in entrambe e' necessario avere un server di gioco pubblico disponibile su Internet. Requisiti per il primo metodo ----------------------------- - un server di gioco che utilizzi un eseguibile modificato per evitare l'invio del comando \disc\ e che rimpiazzi \uoff\ con \uon\ Il risultato e' che un giocatore con una cd-key valida entra nel server dell'attacker ma la sua cd-key rimane in uso quando lascia la partita. Modificare l'eseguibile e' molto semplice ma bisogna ricordare che i comandi non sono in chiaro nel codice ma vengono costruiti in un modo molto semplice a runtime (qualcosa tipo buff[0]='\\'; buff[1]='d'; buff[2]='i'; buff[3]='s'; buff[4]='c'; ... il pattern e' simile per tutti i giochi che utilizzano questo toolkit). Per esempio, in alcuni minuti e con la sostituzione di soli 3 bytes ho modificato con successo l'eseguibile di Gore 1.48: http://aluigi.org/poc/gore148gskeyinuse.zip UPDATE 02 Sep 2005: Added an universal patcher which converts any executable of the games that use the Gamespy cd-key SDK in a proof-of-concept for keeping in use the cd-keys of the gamers that join the malicious server: http://aluigi.org/poc/gskeyinuseuni.zip Requisiti per il secondo metodo ------------------------------- - un normale server di gioco - Gshsniff per catturare le richieste di autorizzazione - il proof-of-concept per replicare le richieste in qualsiasi momento si voglia Una spiegazione e' disponibile nella sezione seguente. ####################################################################### =========== 6) The Code =========== Il proof-of-concept (per sfruttare il secondo metodo) e' composto da questi due programmi: - GsHsniff http://aluigi.org/papers/gshsniff.zip uno sniffer capace di catturare tutte le richieste codificare inviate e ricevute dal master server - Gamespy cd-key validation: "Cd-key in use" DoS http://aluigi.org/poc/gskeyinuse.zip il proof-of-concept vero e proprio, legge tutte le richieste di autorizzazione (in chiaro) contenute in un file e le invia al master server. Inoltre si mette in ascolto su una porta specifica in modo da riportare al master server che le cd-key dei giocatori sono sempre in uso. Utilizzo pratico ---------------- Copia tutte le richieste di autorizzazione collezionate con GsHsniff in un file di testo come keys.txt. Fare cio' e' molto semplice, e' necessario lanciare GsHsniff, avviare un server dedicato del prioprio gioco preferito e poi partecipare al match (naturalmente il gioco deve utilizzare il toolkit di Gamespy per la verifica delle cd-key). Quando viene catturata la richiesta si possono chiudere sia il client che il server di gioco. Il file keys.txt dovrebbe apparire simile al sequente: \auth\\pid\123\ch\aBcDeFg\resp\0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567\ip\123456\skey\1234 \auth\\pid\999\ch\253h2\resp\abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef ... (una sola richiesta \auth\ e' abbastanza, una per ogni cd-key) Lancia gskeyinuse specificando il nome del file di testo contenente le richieste e la porta locale su cui mettersi in ascolto: gskeyinuse keys.txt 7777 Entrambi i tools sono molto descrittivi quindi qualsiasi dettaglio e' sempre visibile e GsHsniff e' utile per vedere in tempo reale cio' che ho provato a spiegare a parole (soprattutto usando al meglio le sue opzioni). Dopo aver lanciato il proof-of-concept si puo' verificare che la cd-key e' in uso entrando in un qualsiasi server di gioco online od utilizzando un programma che ho scritto a tale scopo: http://aluigi.org/papers/gskeycheck.zip Se si riceve l'errore "Cd-key in use" vuol dire che il gioco e' vulnerabile. ####################################################################### ====== 7) Fix ====== Gamespy e' stata contattata e sta' lavorando ad una soluzione. FYI, naturalmente Gamespy e' a conoscenza di questo problema da molti anni in quanto e' saltato fuori durante lo sviluppo del sistema di verifica delle cd-key, ma questa e' un'altra storia... Il fix richiedera' una nuova versione dell'SDK quindi i giochi dovranno implementarlo nelle loro future patch. Tradotto: molti giochi rimarranno vulnerabili per diverso tempo e molti altri lo saranno per sempre perche' non piu' supportati. Naturalmente i giocatori con le cd-key valide possono evitare il problema del "Cd-key in use" con 2 metodi: - giocare solo su server fidati e verificare sempre gli indirizzi IP in quanto e' possibile per un attacker mettere su un server con lo stesso nome e dettagli di un altro - se si pensa che qualcuno tenga la cd-key in uso e' necessario aspettare qualche ora per verificare che la situazione ritorni normale, dopodiche' bisognerebbe contattare Gamespy in quanto loro sono gli unici a conoscere l'indirizzo IP del server dell'attacker Come gia' detto molti giochi non verrano mai patchati quindi bisogna tenere queste semplici regole in mente. #######################################################################