####################################################################### Titolo: In cosa consiste il broadcast exploitation nei videogiochi 0.1 Autore: Luigi Auriemma e-mail: aluigi@autistici.org web: aluigi.org ####################################################################### "Broadcast exploitation" e' uno dei termini (non ho molta fantasia con i nomi) che uso per identificare un tipo di sfruttamento delle vulnerabilita', quindi non un bug specifico ma la via utilizzabile dall'attacker per attaccare le proprie vittime con il minimo sforzo ed il piu' vastamente possibile. Il suo uso e' perfetto per i videogiochi online per via della loro architettura ed al momento non sono a conoscenza di altre tipologie di software che potrebbero essere sfruttati allo stesso modo. Inoltre esso puo' essere applicato sia alle vulnerabilita' nei servers che nei client ma il massimo dei vantaggi si raggiunge solo con questi ultimi in una determinata circostanza. Oramai quasi tutti i videogiochi sono predisposti al gioco online ed immagino che chi stia leggendo questo documento non sappia come funzioni la loro architettura quindi passo a spiegare i passi principali, anche perche' sono essenziali per capire come funziona questo sfruttamento "automatico e passivo" delle vulnerabilita'. L'architettura dei giochi online e' simile a quella del peer2peer, quindi esiste un server centrale chiamato "master server" che e' mantenuto dagli sviluppatori del gioco o da terze parti (Gamespy!?), un po' come accade con i vari programmi p2p che ricevono la lista di servers a cui potersi connettere tramite i servizi come Napigator, NapList, GotNap e tutti gli altri. Il master server infatti non e' nient'altro che un server contenente la lista aggiornata di servers di gioco online quindi ogni client che vuole giocare su Internet fa' una query (ossia lo interroga con una richiesta) per ottenere tale lista. Il client una volta ottenuta la lista passa "automaticamente" (da sottolineare!) all'invio di query ad ogni singolo server contenuto nella lista. Tale operazione ha una duplice utilita': - permette di ricevere informazioni da ogni server come il suo nome, il tipo di partita in corso, i giocatori sul server e cosi' via - sapere se il server e' online ed il ping, ossia se e' abbastanza veloce in modo da avere un gioco senza rallentamenti (lag). Il ping e' il tempo trascorso dall'invio della query sino alla ricezione del reply (ossia la risposta del server) Fin qui mi sembra tutto chiaro, ma ora viene il bello. Immaginiamo che esista un bug nei clients che li fa' crashare se ricevono un particolare reply da parte dei servers, ad esempio un valore in esso contenuto che se troppo grande causa la lettura di una zona di memoria inaccessibile o qualsiasi altra cosa che porti ad un semplice crash del client. Il fatto che il bug sia localizzato nella gestione della risposta alla query automatica del client e' ESSENZIALE altrimenti tale tipologia di sfruttamento non puo' essere applicata ai clients. Un crash in un client normalmente non viene neanche considerato come bug di sicurezza in quanto nessun attacker si prenderebbe la briga di creare un server fasullo con l'unico intento di far crashare il client di qualcuno che dopo pochi secondi ritorna online e su quel server di sicuro non ci entrera' piu'. Ma lo stesso identico bug raggiunge quasi l'apice della criticita' grazie all'architettura e le query automatiche dei videogiochi online. Infatti cosa succede se l'attacker crea un server fasullo (un semplice ricevi-rispondi) fatto appositamente per sfruttare tale vulnerabilita' e lo aggiunge alla lista del master server? Semplice, qualsiasi client al mondo che entra nel menu' multiplayer del proprio gioco (vulnerabile) contatta automaticamente il server malevolo e sempre automaticamente e silenziosamente diviene una vittima dell'attacker non appena riceve la risposta "malformata". Ma passiamo ai PRO ed i CONTRO di tale attacco dal punto di vista dell'attacker: PRO - il tutto avviene automaticamente quindi non c'e' bisogno di spingere i clients a connettersi al server malevolo in quanto il tutto viene fatto in silenzio ed appunto in automatico dal client stesso - completa passivita', una volta che il server malevolo e' nella lista del master server l'attacker non dovra' muovere piu' un dito in quanto non sara' lui a cercare le sue vittime ma saranno loro a venire da lui - anche un bug stupido come un crash del client diviene un ben piu' interessante network DoS, ossia l'intera rete di gioco diviene inutilizzabile in quanto non esistera' piu' nessun client (e senza clients i servers non hanno motivo di esistere). - anonimita' iniziale, ossia il client non sapra' chi e' stato a farlo crashare o ad eseguire codice malevolo su di esso CONTRO - non ci sarebbero dei contro ma se qualcuno volesse potrebbe benissimo contattare tutti i servers online (magari con un tool apposito) per poi individuare i servers malevoli in base alle risposte che inviano, invalidando cosi' l'anonimita' iniziale che ho elencato nei PRO. Inoltre l'IP che c'e' online e' sicuramente quello reale del server, certo potrebbe esistere la possibilita' di falsificare l'IP nella lista ma cio' non sarebbe utile all'attacker che non potrebbe piu' attaccare in quanto i clients si connetterebbero al falso IP anziche' a lui. Una nota andrebbe spesa per una funzionalita' che ho notato raramente e che potrebbe essere usata da alcuni master servers ossia il caching dei reply dei servers che vengono poi inviati dallo stesso master server ai clients in modo da velocizzare le operazioni di selezione del server desiderato a cui partecipare. Tale funzione potrebbe essere utilizzata dall'attacker per far sfruttare la vulnerabilita' dal master server stesso anziche' da lui in prima persona ma e' il caso di non dare troppo peso a questa ipotesi. Per quanto riguarda la possibilita' di far comparire il proprio IP nella lista del master server bisogna sottolineare che tale operazione e' quasi sempre incredibilmente semplice e di solito bastano uno o due pacchetti per far cio' (il primo per richiedere l'inserimento nella lista ed il secondo di solito per confermarla, comunque non tutti i master servers sono uguali) quindi non esiste alcun limite per l'attacker. La stessa lista dei master servers puo' anche essere usata per attaccare i servers vulnerabili in modo automatico ma naturalmente non ci sara' il PRO della passivita' mentre si potra' raggiungere il massimo dell'anonimita' se il bug richiede l'invio di pacchetti UDP facilmente spoofabili e come tutti sanno l'UDP e' il protocollo usato nella maggiorparte dei giochi online. Naturalmente ho anche diversi esempi di bugs che ho trovato e che possono essere sfruttati col metodo appena descritto. Quelli piu' interessanti localizzati nei clients sono i seguenti: http://aluigi.org/adv/cmr4cdos-adv-ita.txt http://aluigi.org/adv/fs2cbof-adv-ita.txt http://aluigi.org/adv/purge-cbof-adv-ita.txt http://aluigi.org/adv/nfshp2cbof-adv-ita.txt http://aluigi.org/adv/hlbof-client-adv-ita.txt http://aluigi.org/adv/ut2003pdos-adv-ita.txt In conclusione e' il caso di dire che non bisogna mai sottovalutare i bugs di sicurezza in quanto anche delle vulnerabilita' che possono sembrare innocue in realta' possono nascondere interessanti potenzialita' in determinate condizioni (ed i videogiochi ne hanno molte di queste condizioni). Per quanto riguarda i videogiocatori invece consiglio di essere sempre aggiornati sulle vulnerabilita' esistenti nei propri giochi preferiti e di stare attenti ANCHE quando si entra nel menu' multiplayer dei loro giochi. #######################################################################