###################################################################### Luigi Auriemma Applicazioni: Motore di rete di Unreal e giochi che supportano files aggiuntivi (mappe, musiche, MODs ed altri) This is the list of the vulnerable games: - America's Army - DeusEx - Mobile Forces - Nerf Arena Blast - Rune - Sephiroth: 3rd episode the Crusade - Star Trek: Klingon Honor Guard - Tactical Ops - TNN Pro Hunter - Unreal 1 - Unreal Tournament <= 436 - Unreal Tournament 2003 <= 2166 - Wheel of Time - X-com Enforcer Versioni: Tutte le 3 versioni del motore di Unreal rilasciate sino ad ora (controlla ogni gioco se e' stato patchato) Piattaforme: Tutte le piattaforme supportate: - Win32 - Linux - MacOS - (anche le console probabilmente, ma con molte limitazioni e comunque sia per il momento cio' e' solo in via teorica) Bugs: Un sacco di problemi (dai un'occhiata nella sezione "Bugs") causati dall'assenza di un handshake tra il client ed il server piu' altri bugs come il bug riguardo gli index number con segno negativo e l'assenza di un controllo delle chiavi generate per ogni match Data: 05 Feb 2003 Autore: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org ###################################################################### 1) Introduzione 2) Riassunto veloce dei bugs (raccomandato) 3) Bugs/effetti (dettagli tecnici): - A] DoS e DDoS generici tramite pacchetti UDP vuoti spoofati - A-1] DoS contro lo stesso server di gioco - A-2] Attacco distribuito di interruzione del servizio - B] "Pranzo" di risorse e crash remoto - C] Server occupato da giocatori inesistenti - D] Bouncing bouncing - E] Esecuzione di codice tramite package files - F] unreal:// crash 4) Il Codice 5) Fix ###################################################################### =============== 1) Introduzione =============== Il motore di Unreal nacque nel 1998 e finora esso si e' evoluto in modo da offrire le massime prestazioni per l'hardware corrente ed inoltre e' stato portato su tantissimi sistemi di cui l'ultimo, in ordine temporale, e' la console Xbox con Unreal Championship (un gioco davvero fenomenale!). Ora esso e' uno dei piu' diffusi motori nella storia dei videogiochi ed e' stato utilizzato per qualsiasi tipo di gioco, dagli sparatutto in prima persona ai giochi di flipper. Questo motore al momento e' diviso in 4 grandi release che sono: - Original build (prima release): 226f --> 220 - Tournament build (seconda release): 220-224 --> 300-436 - Championship build (terza release): 436 --> ??? - Warfare build (quarta release): non disponibile al momento (grazie a http://wiki.beyondunreal.com/wiki per queste info) Questo motore e' quindi usato da molte compagnie che producono videogiochi come "scheletro" per i loro giochi e la lista infatti e' molto lunga. I giochi vulnerabili possono comunque essere controllati alla voce "Applicazioni" in alto a questo advisory/documento. L'evoluzione del motore contiene nuovi effetti grafici e sonori, una nuova e strepitosa simulazione di movimento (karma engine), nuove API e molte altre ottimizzazioni. Comunque c'e' ancora una sezione del motore che non si e' evoluta come altre parti piu' "visibili" (come ad esempio la parte grafica): il protocollo di rete. Il protocollo di rete in Unreal infatti soffre di molti problemi e la cosa piu' importante (la base di quasi tutte le vulnerabilita' che lo affliggono) e' la completa assenza di un reale handshake tra il client ed il server. L'altro problema, ed io penso sia anche il piu' pericoloso, e' che il motore di Unreal ha problemi nella gestione dei numeri con segno negativo (leggi il punto B ed E nella sezione Bugs per maggiori dettagli) che causano un incredibile consumo di risorse e persino l'esecuzione di codice. La cosa spaventosa in tutto cio' e' facilmente intuibile: per 5 anni, dal lontano 1998, tutti i giochi basati sul motore di Unreal sono potuti essere bersaglio di qualsiasi attacker che fosse stato a conoscenza di tali bugs... Davvero terrificante. La "storia" della mia ricerca riguardo il motore di Unreal e' davvero molto semplice: quando e' stato rilasciato il demo di UnrealTournament 2003 nella seconda meta' del 2002 ho deciso di verificare se Epic (Epic Games) avesse finalmente introdotto un handshake o almeno avesse cambiato o corretto il protocollo di rete al fine di evitare gli attacchi DoS e DDoS che avevo segnalato nella precedente versione di UnrealTournament (http://aluigi.org/adv/ut-adv.txt)... ma con mia grande sorpresa non era presente nessun cambiamento. Cosi' un po' per curiosita' ed un po' per sfida ho deciso di testare il gioco alla ricerca di altre possibili vulnerabilita'. I risultati di questa mia ricerca sono in questo documento. Buon divertimento! ###################################################################### ============================ 2) Riassunto veloce dei bugs ============================ 1] Il motore di Unreal non supporta un handshake tra il client ed il server, di conseguenza un attacker puo' sfruttare attacchi DoS, DDoS e bounce tramite l'utilizzo di pacchetti con mittente falso. 2] Il motore di Unreal usa le challenge keys per identificare ogni partita ma, non so per quale motivo, sembra che in realta' tali chiavi nelle risposte del client non siano controllate dal server ed inoltre non effettua nessun altro controllo aggiuntivo per evitare che un attacker possa aggiungere nuovi giocatori inesistenti con estrema facilita'. 3] Il motore di Unreal ha diversi problemi nel gestire numeri con segno negativo (usati per indicare la grandezza dei dati). - Se un attacker utilizza un numero negativo nei pacchetti di rete, il server che utilizza il motore di Unreal iniziera' ad allocare una quantita' di RAM che e' uguale al numero senza il segno oppure crashera' immediatamente se tale numero e' maggiore dell'ammontare di RAM allocabile. - Se l'attacker usa i package files (come le mappe ad esempio), egli puo' facilmente eseguire codice sulla macchina della vittima che ha utilizzato il file, in quanto il bug usato nel package file permette all'attacker di sovrascrive il registro EIP e inserire in memoria tutto il suo codice (senza limitazioni). 4] Problemi con gli URLs di Unreal (unreal://...) ###################################################################### ================================== 3) Bugs/effetti (dettagli tecnici) ================================== Come detto nell'introduzione, esistono 3 release del motore di Unreal al momento (inizio del 2003) e l'ultima e' iniziata con la comparsa di UnrealTournament 2003 quindi quando parlero' di UT2003 bisognera' considerarlo come un riferimento generico al motore di Unreal o piu' semplicemente un esempio pratico reale. TUTTE le release del motore sono vulnerabili ai bugs che ho trovato perche' il protocollo di rete e parte del suo codice interno non sono stati modificati dalla prima release del motore. Naturalmente "qualcuno" dei miei exploits non puo' girare su tutte le versioni del motore o su tutti i giochi in quanto ho concentrato i miei test esclusivamente su UT2003 (comunque non c'e' problema perche' sono appena 2 o 3 gli exploit che devono essere appena modificati per un gioco od una versione del motore specifica). Ecco tutti i dettagli dei problemi che ho trovato: ----------------------------------------------------------- A] DoS e DDoS generici tramite pacchetti UDP vuoti spoofati ----------------------------------------------------------- Se si prova ad inviare un solo pacchetto UDP alla porta di gioco di un server di UnrealTournamente 2003 (7777 di default) si iniziera' a ricevere una quantita' di 4 o 5 pacchetti al secondo da tale server. Il timeout di default per tali pacchetti e' di 200 secondi (quindi 50 secondi in piu' al timeout del precedente UT, causato dalla durata dei caricamenti piu' lunga). Se si guarda nella console del server di UT2003, appena il client invia il pacchetto UDP, si vedra' una stringa simile a questa: - NotifyAcceptingConnection: Server myLevel accept Open myLevel 11/10/02 09:56:08 192.168.0.3:32768 - Grandioso, il server ha appena accettato una connessione grazie ad un semplicissimo datagramma UDP vuoto 8-) Infatti il reale problema e' che non esiste un handshake per gestire le connessioni, mentre dobbiamo ricordare che tutti i giochi online del mondo usano un handshake (anche se minimale): QuakeIII, Half-life, etc... sono solo degli esempi (ok, Half-life ha un bug proprio nella gestione di tale handshake ma almeno e' stato implementato e poi nessuno e' perfetto...). Dopo i 200 secondi di timeout finalmente il server ferma il suo piccolo flooding e mostrera' il seguente messaggio nella console di UT2003: - Connection timed out after 200.000000 seconds (200.049645) Close TcpipConnection 11/10/02 09:59:28 - Le conseguenze di questo problema sono essenzialmente due: -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- A-1] DoS contro lo stesso server di gioco -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Tutto cio' che dobbiamo fare e' inviare un pacchetto UDP dal server a se stesso, con una porta sorgente che sia differente per ogni pacchetto (ad esempio sequenziale o casuale) e con la porta di gioco standard usata come porta di destinazione. Esempio: 1.2.3.4:1 --> 1.2.3.4:7777 1.2.3.4:2 --> 1.2.3.4:7777 ... 1.2.3.4:65535 --> 1.2.3.4:7777 Dopo una grande quantita' di datagrammi ricevuti il server iniziera' ad andare molto lento, talmente lento che diverra' impossibile giocare. Il PentiumII a 448Mhz usato per questi test e' arrivato a mostrare 1 frame ogni 3 o 4 secondi! Questi interessanti effetti sul sistema usato come vittima di questo tipo di attacco sono i seguenti: Sistema: Pentium II 448 Mhz (112 FSB x 4.0) Pacchetti usati: 1000 Utilizzo RAM: 17 Mb * Utilizzo CPU: 40% ** * (RAM durante l'attacco meno RAM prima dell'attacco) ** (CPU durante l'attacco meno CPU prima dell'attacco) Ora sei pronto a vedere il tuo nuovo AthlonXP andare veloce quanto un 486? 8-) -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- A-2] Attacco distribuito di interruzione del servizio -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Penso che chiunque ora abbia intuito di quanto possa essere pericoloso un server di UT2003 se un attacker usera' migliaia di questi servers su una connessione internet ad alta velocita' per creare una rete DDoS. L'attacker non ha bisogno di installare tools DDoS su macchine crackate o aspettare la propagazione di un suo worm. Si possono trovare liste di servers di giochi basati sul motore di Unreal ovunque! Un esempio veloce consiste nel puntare il browser ai seguenti indirizzi URL che sono le lista aggiornate in tempo reale dei servers di gioco di UT2003 (sia il gioco completo che il demo): http://ut2003master.epicgames.com/serverlist/full-all.txt http://ut2003master.epicgames.com/serverlist/demo-all.txt Inoltre si possono trovare molti altri servers tramite i Master servers usati da Gamespy. Un'altra possibilita', davvero "cattiva", di tale attacco consiste oltre che nel bloccare totalmente un host, soprattutto nel dare un brutto colpo al portafoglio di quelle persone che pagano il proprio accesso ad Internet in base al traffico di rete. ------------------------------------- B] "Pranzo" di risorse e crash remoto ------------------------------------- Il bug piu' interessante che ho trovato durante la mia ricerca e' il seguente. Un pacchetto forgiato ad arte puo' far crashare immediatamente QUALSIASI server che usa il motore di Unreal: tutte le versioni sono vulnerabili allo stesso pacchetto! Prima di passare ai dettagli del problema, e' meglio dare un'occhiata alle "basi" del motore di Unreal: Il motore di Unreal usa un metodo (un po' strano) per usare meno spazio all'interno dei files e dei pacchetti di rete. Questo metodo e' chiamato "index type" o "Compact indices" e non e' nient'altro che un numero di tipo long (31 bits + 1 bit per il segno) che viene salvato utilizzando uno spazio compreso tra 1 e 5 bytes (un numero di tipo long occupa 4 bytes, quindi tale tecnica e' utile per piccoli valori). In ogni pacchetto inviato sulla rete, prima di ogni "dato" c'e' uno di questi numeri index che specifica la grandezza del dato dopo di esso. In ogni pacchetto ci possono essere piu' "dati" ed il seguente e' un esempio: Esempio: [index1][data1][index2][data2]...[indexN][dataN] Il motore di Unreal per prima cosa decodifica il pacchetto e poi legge il numero index per finalmente allocare tale grandezza in memoria. A quanto ho potuto vedere sembra che il motore di Unreal esegua un piccolo controllo sull'index number per evitare possibili abusi se un attacker prova a settare un numero troppo grande (qualcosa tipo: "if(index_number > packet_or_file_size) break;"), ma sfortunatamente il motore non controlla anche il segno e quindi il server remoto provera' ad allocare tutta la memoria specificata. Esempio: Se io voglio che il server remoto allochi 512 Mb di RAM per leggere il mio pacchetto, non dovro' usare 512000000 (che dovro' poi convertire nel formato index) ma usero' -512000000 in modo da bypassare i presunti controlli del motore. Semplice e divertente. Il massimo numero di bytes allocabili in memoria sono il valore massimo di un numero di tipo long, quindi 0xffffffff meno il primo bit a sinistra che funge da segno: 2147483647 bytes. Gli effetti di questo attacco sono davvero incredibili: - se l'ammontare dei bytes da allocare e' minore alla memoria disponibile sul computer remoto, l'utilizzo di CPU salira' al 100% e verranno consumati tutti i bytes specificati dall'attacker. Questo effetto continuera' per una quantita' di tempo variabile che dipende dall'ammontare dei bytes da allocare e soprattutto dalle performance della macchina vittima (velocita' della CPU e della memoria in particolare). Per esempio sul mio PII a 448 Mhz ci vogliono oltre 25 secondi per allocare 250 Megabytes in memoria (usando il server UCC.EXE, quindi senza l'ulteriore peso di grafica, sonoro ed intelligenza artificiale del gioco). Durante questo tempo sembra che il server non possa maneggiare i pacchetti di rete di Unreal. Se invece di usare il server dedicato giocassimo sul nostro server, il gioco si blocchera' totalmente per un tempo variabile di secondi. - se la memoria che deve essere allocata e' superiore a quella disponibile, il server crashera' immediatamente! Quest'attacco e' il metodo piu' veloce per crashare, bloccare o consumare la memoria di OGNI server basato sulla tecnologia di Unreal e naturalmente e' anche il piu' sicuro per via dello spoofing dei pacchetti. Da come si puo' immaginare tramite una lista di servers un attacker puo' buttare giu' quante partite vuole o semplicemente bloccarle per quanto tempo vuole. ------------------------------------------- C] Server occupato da giocatori inesistenti ------------------------------------------- Uno dei bugs classici dei videogiochi e' quello di far entrare nuovi giocatori in una partita online ma con una piccola differenza... tali giocatori in realta' non esistono 8-) Come in un bug che trovai non molto tempo fa' su Half-Life (http://aluigi.org/fakep.htm solo per partite in multiplayer senza l'autenticazione WON) anche il motore di Unreal e' vulnerabile ad un attacco simile ma che e' piu' semplice da eseguire rispetto a quello di Half-Life. Incredibilmente nel motore di Unreal non solo manca un vero handshake ma la challenge key (ossia la chiave che viene solitamente creata per ogni match ed evitare abusi) non e' considerata dal server, quindi l'attacker puo' usare semplicemente la stessa chiave o usarne una generata in modo casuale. In conclusione cosa significa tutto cio'??? Semplice, i pacchetti che sono inviati da un giocatore al server per poter entrare nella partita possono essere gli STESSI tutte le volte quindi in questo modo un attacker puo' usare gli stessi pacchetti UDP usati precedentemente senza conoscere il protocollo o perdere tempo a reversare l'algoritmo di codifica/decodifica di Unreal. Ma non solo questo, l'attacker difatti puo' usare pacchetti UDP con falso mittente senza problemi in quanto egli non ha bisogno di conoscere alcuna challenge key e quindi neanche le risposte del server. Questi "pacchetti usati nel handshake" sono generalmente 4 datagrammi UDP che contengono le seguenti informazioni: 1) Messaggio "Hello" con versione del client 2) Informazioni che ci riguardano quali velocita' della rete, user e password, classe, personaggio, team, challenge key (inutile) ed altre informazioni 3) Prima parte dei checksum dei files (penso che essi siano i checksum dei files nei package files o qualcosa di simile) 4) Seconda parte dei checksums piu' la stringa Join L'effetto di questo attacco e' molto semplice: i giocatori umani non possono accedere ad un server sotto questo tipo di attacco in quanto esso e' pieno. (Basta premere F1 durante l'attacco per vedere tutti i giocatori fasulli) Una caratteristica particolarmente interessante che ho notato in UT2003 e' che questi giocatori fasulli non possono essere visti da un giocatore esterno che guarda le informazioni del server in quanto quest'ultimo non mostra questi falsi giocatori nella lista corrente (ad esempio in UT2003 noi vedremmo 0/32 giocatori correnti nel match ma se proviamo a entrare anche noi, il server ci rispondera' che e' pieno). In pratica da fuori il server sembra vuoto ma in realta' esso e' pieno di giocatori inesistenti e rimarra' cosi' finche' l'attacker non decide di fermare l'attacco. -------------------- D] Bouncing bouncing -------------------- Un altro attacco abbastanza interessante che puo' essere portato verso il motore di Unreal e' il "bounce" in quanto il protocollo di rete permette ad un attacker di usare i server di Unreal come una partita a ping-pong; i pacchetti UDP possono essere fatti rimbalzare da un server ad un altro o semplicemente contro lo stesso server in un loop infinito. Tutte le versioni del motore di Unreal sono vulnerabili con l'unica differenza delle porte vulnerabili usate dal gioco. Per esempio la porta dati di UT2003 (7777 di default) non gestisce lo stesso pacchetto che proviene da una porta ed un IP gia' gestiti precedentemente. Invece per UnrealTournament la porta sorgente non e' considerata, quindi noi possiamo tranquillamente usare la porta dati (7777). Voglio soltanto aggiungere che questo attacco e' molto interessante per l'attacker in quanto non ha bisogno di effettuare un flooding UDP o spendere parte della sua banda, lui ha bisogno di un solo datagramma UDP... davvero divertente! Il massimo traffico raggiunto sulla mia interfaccia di loopback e' stato di 5500 pacchetti per secondo con un solo pacchetto inviato... davvero non male se pensiamo che il gioco era emulato con Wine sotto Linux su di un Athlon XP1800+ 8-) --------------------------------------------- E] Esecuzione di codice tramite package files --------------------------------------------- Questo e' l'ultimo bug ma anche il piu' pericoloso che ho trovato durante la mia ricerca non solo perche' un attacker puo' eseguire codice sul sistema della vittima ma specialmente perche' sia i giochi che supportano il multiplayer che quelli che non lo supportano sono vulnerabili. Infatti TUTTI i giochi che usano il motore di Unreal sono vulnerabili perche' questo non e' un bug riguardante il motore di rete che alcuni giochi possono non implementare, ma e' un problema del motore interno (quindi la lista dei giochi vulnerabili in alto a questo advisory puo' essere anche piu' lunga). Il problema e' nella lettura dei package files. Una descrizione dettagliata del formato dei package files e' stata scritta da Antonio Cordero ed e' chiamata "UT Package File format" http://www.acordero.org Molto velocemente, package file e' un formato usato dal motore di Unreal per leggere ed immagazzinare dati quali musica, textures, mappe, suoni e qualsiasi altro tipo di dato. In ogni package file ci sono 3 sezioni: name, import ed export. La seguente struttura fa' riferimento alla sezione name (che sembra essere l'unica vulnerabile a questo bug): - index type: lunghezza della stringa name (compreso il byte NULL finale) - char *name: il nome della stringa ("None\0" o "LevelInfo\0" per esempio) - u_long: flags Un esempio di sezione name e': "\x05None\x00\x10\x04\x07" che e' usata in quasi tutti i package files di ogni gioco; possiamo infatti vedere il byte 0x05 che si riferisce alla stringa "None\x00". Il problema sorge quando l'attacker modifica questo "valore della lunghezza della stringa" con uno di segno negativo (-512 invece di 512 ad esempio). Per avere maggiori informazioni riguardo i numeri index basta dare un'occhiata al bug [B] oppure leggere il documento "UT Package File format" di Cordero all'apposita sezioni riguardante gli Index types. I giochi basati sul motore di Unreal inizieranno a leggere una quantita' di dati dal file (24512 bytes nel mio exploit ut-ucc436) ma successivamente avranno problemi nel gestire l'index number malformato. Il seguente e' un esempio che utilizza il file mappa entry.unr di UnrealTournament come base del nostro attacco su un sistema Win98 su cui gira UnrealTournament v436 (UCC.EXE nell'esempio): All'offset 0x00000040 troviamo il byte che e' usato per specificare la lunghezza della stringa "None\0" che naturalmente e' 5. Quindi invece di scrivere "\x05None\0" (5 + "None\0") scrivero' "\xffNone\0"; a questo punto il server leggera' il tutto come 0xff4e (ossia l'index number che e' uguale a -5055) + "one\0". Il bug del segno negativo ha colpito in pieno e stavolta ci fara' divertire davvero parecchio 8-) Il registro EIP sara' sovrascritto dalla DWORD all'offset 0x000000fe e (sul mio sistema) TUTTI i bytes dall'inizio dell'offset 0x0000004c sino a 0x0000066f andranno a finire nello stack a partire dalla posizione 0x006493e0 (ESP + 0x2424). Quindi un attacker puo' usare uno spazio davvero enorme e per di piu' definito da lui stesso!!! Ricapitolando, il seguente e' un piccolo riassunto sui dettagli dell'esempio appena proposto: --- Stringa usata = "\xffNone\0" Offset dei registri EIP e ESP: EIP in memoria = 0x04001000 offset di EIP nel file = 0x000000fe ESP = 0x006493e0 Prima parte del file mappa che verra' posizionata in memoria ("one\0\x10\x04\x07\x04..."): In memoria = da> ESP + 2424 -a-> ESP + 24e0 Nel file = da> 0x00000042 -a-> 0x000000fd Seconda parte del file mappa che andra' in memoria ("ayer\0\x10\x04..."): In memoria = da> ESP + 24e8 -a-> ESP + 2a50 Nel file = da> 0x00000106 -a-> 0x00000066f --- NOTA: Se si ha intenzione di creare un file mappa per far eseguire del codice, consiglio di inserire lo shellcode nella seconda parte del file mappa!!! L'ultima cosa pericolosa riguardo a tale bug riguarda la diffusione di package files malformati in quanto nessuno (che non sia un ricercatore di bugs o una persona davvero paranoica) puo' avere il minimo sospetto riguardo un file mappa, una nuova texture o il nuovo suono per il suo gioco preferito. Quanti file mappa hai scaricato felicemente per il tuo gioco preferito senza pensare alla propagazione di informazioni personali, accessi remoti al tuo sistema o danni hardware o software? L'unico limite per un attacker e' che i package files malformati non possono essere diffusi tramite il server UCC e quindi inviati al client perche', naturalmente, il server crashera' quando lo leggera'. (inoltre non e' neanche possibile usare prima un file originale e poi sostituirlo con quello malformato perche' il server si rifiutera' di inviare la mappa al client, ma sinceramente non so per quale motivo...). ------------------ F] unreal:// crash ------------------ Dopo oltre 2 mesi dalla segnalazione alla Epic del primo problema ho trovato questi altri bugs. Il primo problema e' nell'URL "unreal://" in quanto una stringa host troppo lunga provochera' il crash del gioco. Il bug sembra essere causato da Msvcrt.dll e l'effetto e' la possibilita' per un attacker di sovrascrivere una parte del registro EIP. Fortunatamente per i giocatori la stringa/host dopo unreal:// e' immagazzinata in memoria come una sequenza di WORD e non come char, quindi l'EIP puo' essere sovrascritto solo con "\x00 char2 \x00 char1"; penso sia davvero difficile (od impossibile) per un attacker di eseguire codice sulla vittima con questo bug. L'URL di Unreal di esempio per Unreal Tournament e' il seguente: unreal://(261 chars)[EIP_byte][EIP_byte] Quindi "unreal://(261 of 'z')ut" sovrascrivera' l'EIP con 0x00740075. Un possibile utilizzo di questo URL e' su IRC contro il client IRC del gioco (usato per esempio in Unreal Tournament) che crashera' quando l'utente eseguira' un singolo click sull'URL. FYI, l'URL unreal:// e' vulnerabile anche al directory traversal bug che non e' pericoloso in questo caso ma puo' dare problemi se la vittima ha un "normale" file sul suo sistema (un file che non sia un package file come ad esempio un file vuoto) senza estensione che puo' essere lanciato semplicemente tramite unreal://file (o unreal://\directory\file se si vuole utilizzare il directory traversal bug) perche' il gioco provera' a cercare nelle sue directory il file specificato dall'attacker e successivamente con le estensioni delle mappe, textures, suoni e file di musiche. L'effetto per un file vuoto e' il crash istantaneo del gioco. Comunque IMHO questi 2 problemi sono un po' difficile da usare ed i loro effetti sono un DoS limitato. ###################################################################### ============ 4) Il Codice ============ Ho scritto e rilasciato molto codice per testare i problemi descritti in questo documento ed i loro effetti. Al momento ho basato il mio codice su UT2003 (ossia la terza release del motore di Unreal) ma quasi tutto i miei proof-of-concept possono essere utilizzati anche per altri giochi o versioni del motore. Inoltre gran parte del codice puo' anche essere compilato su Win32 (solamente dove non e' necessario lo spoofing in quanto voglio che tutti i sistemi Win32 possano usufruire degli stessi programmi, Win9x compreso). ----------------------------------------------------------- A] DoS e DDoS generici tramite pacchetti UDP vuoti spoofati ----------------------------------------------------------- -_-_ A-1] -_-_ Il primo tool che voglio descrivere e' stato ideato per lanciare attacchi DoS contro lo stesso server basato sul motore di Unreal ed e' stato chiamato "Unreal engine loopback DoS" (solo per Linux). Con esso si potra' testare meglio quanto lento puo' divenire il proprio PC/server durante l'attacco: http://aluigi.org/poc/unrdos.c (il valore di timeout e' quello di UT2003, quindi se si ha intenzione di testare altri giochi bisogna ricordarsi di cambiare tale valore) -_-_ A-2] -_-_ Il tool piu' importante che ho scritto e' UTDDoS. La nuova versione sulla mia pagina personale ora supporta anche i servers di UT2003 (oltre che quelli di UnrealTournament). Bisogna comunque ricordare che tale tool e' molto pericoloso ed e' stato creato con l'unico scopo di testare tali bugs. (Per compilarlo si ha bisogno di Libnet 1.1.0 o superiore e Linux: http://www.packetfactory.net/libnet) http://aluigi.org/poc/utddos.c ------------------------------------- B] "Pranzo" di risorse e crash remoto ------------------------------------- Per TUTTI i giochi. (codice sia per Linux che per Win32) http://aluigi.org/poc/unrcrash.zip ------------------------------------------- C] Server occupato da giocatori inesistenti ------------------------------------------- Specifico per UT2003 (testato solo il DEMO del gioco). Se si vuole far andare il codice su altri giochi basta solo cambiare le stringhe dei #define. (codice compilabile per Linux e Win32) http://aluigi.org/fakep/ut2003fake.zip -------------------- D] Bouncing bouncing -------------------- Specifico per UT2003. Per usarlo su altri giochi basta cambiare i #define (codice solo per Linux) http://aluigi.org/poc/ut2003bounce.c --------------------------------------------- E] Esecuzione di codice tramite package files --------------------------------------------- L'exploit piu' tecnico della "collezione"... Esso e' una file mappa per UnrealTournament v436 per Win98 SOLTANTO. http://aluigi.org/poc/ut436.unr.zip Nello zip ci sono 2 mappe, una da utilizzare con il server UCC (ut-ucc436.unr) e l'altra per il gioco (DM-ut436.unr). La prima mostrera' un messaggio nella console ed uscira'. La seconda mappa invece mostrera' un MessageBox e successivamente uscira'. (puo' capitare su alcune macchine che il MessageBox impieghi alcuni secondi prima di comparire) Entrambi i file mappa sono stati scritti solo per sistemi Win98. --- A proposito di tale bugs ho anche scritto un semplice controllore per i package files utilizzati da qualsiasi gioco basato sul motore di Unreal: http://aluigi.org/papers/unrcheck.zip ------------------ F] unreal:// crash ------------------ unreal://(261 chars)[EIP_byte2][EIP_byte1] or unreal://(258 chars) unreal://\directory\file o ogni altra modifica come unreal://..\..\directory\file --------------------------------------------------- UDP Sniffer + ENC/DECoder di Unreal (sperimentali!) --------------------------------------------------- Ho anchre scritto un semplice UDP sniffer per uso privato che ha la capacita' di decodificare in tempo reale i pacchetti di rete usati dai giochi basati sul motore di Unreal. Data la sua possibile utilita' ho pensato che sia una buona idea rendere disponibile tale utility a chiunque. Il programma gira sia su Linux che sui sistemi Win32 (Win32 ha bisogno di Winpcap che puo' essere trovato su http://www.winpcap.org) http://aluigi.org/papers/unrsniff.zip --- Il decoder e l'encoder possono essere scaricati da qui: http://aluigi.org/papers/unrenc.zip http://aluigi.org/papers/unrdec.zip NOTA: - Come scritto nell'intestazione queste applicazioni sono sperimentali in quanto non ho reversato completamente tutto l'algoritmo, ma ho usato alcuni trucchetti per leggere i pacchetti. Comunque gli unici pacchetti interessanti da leggere sono i primi 4 o 5 di ogni connessione perche' contengono dati interessanti riguardo la procedura di immissione nel match ed un sacco di info sul client ed il server. - I primi 2 bytes di ogni pacchetto sono il "contatore di pacchetti" ma ho preferito decodificare/codificare TUTTI i bytes nei pacchetti (quindi anche tali bytes) ###################################################################### ====== 5) Fix ====== IMPORTANTE! Epic ha aspettato moltissimo tempo senza fare nulla riguardo tali problemi. Quando hanno deciso di contattarmi l'unica cosa che mi e' stata detta era che stavano lavorando sui bugs... dopo oltre un mese nessuno mi ha fatto avere informazioni riguardo la risoluzione dei problemi... Il risultato e' che dopo quasi 3 mesi dalla prima segnalazione ed oltre 6 mesi dalla segnalazione degli attacchi DoS ed DDoS su UnrealTournament (che naturalmente coinvolgevano TUTTI i giochi basati sul motore di Unreal) nessuno ha preso con serieta' tali problemi. Ora i problemi sono pubblici quindi ognuno puo' decidere se tali problemi sono seri o no! --- Un fix iniziale e' offerto dagli ISP (i fornitori di accesso Internet) che finalmente si sono decisi a bloccare i pacchetti spoofati inviati dalle loro reti quindi ALCUNI dei bugs in questo documento non possono essere utilizzati da chiunque. UnrealTournamente e' stato patchato per il Dos & DDoS generico nel Settembre 2002, ma tale patch e' inutile se il gioco viene fatto girare sui sistemi Win9x. Ho scritto un semplice controllore dei package files che mostra se un file e' stato modificato o puo' dare problemi al motore di Unreal: http://aluigi.org/papers/unrcheck.zip Per gli altri bugs bisogna solo aspettare le patch degli sviluppatori dei giochi interessati dai problemi. ######################################################################