L’esistenza di soggetti malevoli, che conducono attacchi diretti alle land in Second Life, è storia vecchia. Ci sono sempre stati individui che per divertimento, interesse, vendette varie hanno portato attacchi tesi a interrompere il servizio in determinate regioni. Si tratta di soggetti che hanno una certa conoscenza dei tool della piattaforma, e che mirano a causare un sovraccarico computazionale su una determinata istanza del simulatore, in modo da provocarne il crash sistemico.
Questi attacchi sono classicamente condotti con degli script abbastanza banali, che mandano in esecuzione delle istruzioni in “loop”, in un circolo senza uscita, in modo da sovraccaricare le risorse assegnate a quell’istanza di simulatore dal server. Un altro sistema è quello dei “megaprims” che invadono tutte le risorse dedicate al building, provocando, anche in questo caso, il sovraccarico delle risorse elaborative assegnate a quella land.
Ci sono ovviamente varie versioni di queste due tipologie di attacco, anche abbastanza complesse, in modo da camuffare gli script “avvelenati” o indurre gli utenti ad accettare payload malevoli che veicolano il software di attacco. La tipologia classica del phishing, usata in questi casi, è abbastanza riconoscibile per gli utenti più avveduti, e quindi si può contrastare facilmente, con condotte prudenti verso “offerte” non ben identificate.
Una ipotesi di studio è poi il cosiddetto “attacco DOS” o anche un DDOS, condotto in questo secondo caso da una rete di macchine bot appositamente compromesse in precedenza. Un attacco di tal genere dovrebbe essere rivolto ai server su cui girano i simulatori di Second Life, e mi sento di escludere in partenza questa ipotesi, dato che dal 2020 è terminata la migrazione dei server della Linden Lab sul Cloud AWS di Amazon, e non basterebbero quattro scannagatti per attaccarli, per i sistemi di difesa che ogni Cloud Services Provider attua in modo molto efficace e professionale.
Un’ultima cosa devo dire, riguardo alla considerazione e alla condiscendenza verso determinati personaggi che seguono questa pratica di attacco, o si organizzano in gang. Il modo migliore per difendersi, come ci hanno insegnato anni di lotta alla criminalità organizzata, è quello di isolarli, di non accettare amicizie ambigue, di non inserirsi in qualche gang, e tantomeno assoggettarsi alla “protezione”, nel caso venisse offerta in cambio di amicizia e condiscendenza, o addirittura assumendoli come “protettori” dietro compenso (“security”). Oltre ad essere moralmente riprovevole, si potrebbe configurare il reato di fiancheggiamento se si scoprisse che trattasi di estorsione, comunque camuffata.
Questa la problematica da affrontare, e ora passiamo alle contromisure.
Innanzitutto, occorre raccogliere informazioni sull’”incidente” e fornire al supporto della Linden Lab tutti i dettagli raccolti, compresi quelli dell’autore dell’attacco, se identificato, e formalizzare un “Abuse Report” per la violazione dei ToS relativi alla sicurezza. Questo passo è fondamentale, per rendere evidente l’esistenza di questi attacchi ed il numero di questi, anche riconducibili a specifici account. Se questi AR non venissero fatti, la Linden Lab non avrebbe modo di venire a conoscenza del problema, e tantomeno dedicare risorse per prevenirne altri. Il numero di AR risulterà quindi determinante per dare ai ticket aperti il giusto livello di priorità, nella coda delle centinaia di richieste che un servizio di supporto riceve tutti i giorni da ogni parte del mondo.
Il Service Management si basa sulle priorità, prima vengono gestiti gli incidenti “catastrofici” (ad esempio falle di sicurezza, caduta di server di un’intera regione, azioni di violazione di normative o leggi vigenti, ecc.), sono i cosiddetti “Major Incident”.
Con minore priorità vengono poi gestiti gli incidenti “gravi”, quelli “lievi” e di seguito quelli “normali”. E ogni azienda ha la sua organizzazione per gestirli nella maniera più efficace. È del tutto evidente che nessuna azienda ha risorse infinite, e deve quindi lavorare per priorità dettate dalla gravità e dall’impatto provocato dall’incidente, pur nel rispetto degli obblighi di servizio.
Aprire un ticket, descrivendo bene le circostanze e la gravità del fenomeno, è fondamentale, e quanti più ticket vengono aperti, più l’incidente diventa grave, sale nella classifica delle priorità, e prima viene gestito. Questa la base di partenza di ogni contromisura, effettuare un AR, nel numero appropriato al numero di incidenti che si verificano.
In seguito all’apertura dei ticket il risultato che ci si potrà attendere sarà quello del “ban” dell’account incriminato, con la perdita dell’identità del personaggio, e di tutte le risorse accumulate nell’inventario del soggetto bannato. Questa è la procedura standard, che per un griefer incallito e organizzato può avere un effetto molto limitato, visto che può creare altri accont e proseguire nella sua attività di attacco. Un danno maggiore gli viene provocato se l’account deteneva nell’inventario beni o script importanti e di valore, in questo caso la perdita sarebbe anche economica. Altro danno, collaterale, è la perdita di un Avatar riconosciuto e rispettato da un certo ambiente.
Quindi il ticket, per quanto indispensabile per le ragioni che abbiamo detto, non basta. A meno che il livello di attacco non acquisisca caratteristiche assimilabili ai reati comuni, come il taglieggiamento, o la violazione palese, e legalmente rilevante, di norme relative alla privacy. Il taglieggiamento fa identificare l’aggressore come appartenente alla categoria dei criminali, per cui possono essere attivate le forze dell’ordine, cosa che dovrebbe essere fatta da chiunque subisca azioni penalmente rilevanti, o che abbiano creato danni economici. Per procedere occorre identificare univocamente l’aggressore reale, con nominativo e località. Dobbiamo ricordare, se ancora fosse necessario, che le leggi dello Stato valgono sempre, anche in ambienti virtuali, e nessuno può contare sull’impunità.
Sono, in questi casi, indagini molto complesse, perché naturalmente non basta l’indirizzo IP dell’attaccante, che di solito è un indirizzo variabile, o mascherato da accessi via VPN, o anche su rete decentralizzata peer-to-peer. Per individuare il soggetto sarebbe necessario aprire una investigazione, e condurre indagini approfondite, anche con il supporto delle autorità competenti. Quindi questa strada è molto lunga e tortuosa, ma alla fine produce danni notevoli all’attaccante, con conseguenza legali ed economiche.
Questi passi, seppure non risolutivi, sono però essenziali, per spingere il gestore del servizio a migliorare le contromisure di tipo software nella difesa delle land, contromisure comunque che sono già parte integrante delle difese possibili su una land.
E veniamo infine alle contromisure immediate e, nella gran parte dei casi risolutive, per contrastare gli attacchi. Sono le misure di sicurezza della land da impostare:
- Disattivare gli script
- Assegnare il building solo ad uno specifico gruppo di staff
- Impostare il tempo di return degli oggetti ad un valore molto basso
- Impostare l’accesso ad un gruppo di “amici” limitato
- Limitare la complessità degli avatar sulla land ad un valore non “illimitato”
- Disattivare la visibilità dell’avatar, dalle impostazioni del territorio, in modo che non ci sia visibilità fuori dalla land
- Impedire la riproduzione di suoni da altri avatar esterni al gruppo
- Inserire tutti i nominativi dei greafer noti nella black list di land. Opportuno sarebbe lo scambio di informazioni tra gli owner, usate pure il Gruppo di Cybersecurity per scambiarvi i dati
- Inserire dei dispositivi di sicurezza sulla land, usando quelli in dotazione o anche acquistati da vendor certificati
Tutte queste cautele vanno graduate a seconda delle necessità, ma sono la barriera di sicurezza più efficace per contrastare gli attacchi. Sarebbe opportuno avere delle land su Mainland, il territorio gestito dalla Linden Lab, piuttosto che affittarle da un real estate privato, e sarebbe anche opportuno avere il controllo di una intera sim, in modo da poter controllare tutte queste impostazioni direttamente, e non tramite il proprietario, non sempre disponibile a adottare queste contromisure.
Il problema naturalmente è il costo, ma credo che con opportune politiche collaborative, di tipo “consortile” tra più owner fidati, si possa procedere ad una ripartizione opportuna della sim in parcel individuali, suddividendo in tal modo il costo. Si avrebbe così il pieno controllo di una intera sim su Mainland.
La sicurezza informatica non ha un unico elemento risolutivo, è fatta da tanti “strati”, ognuno importante, è quella che in Cybersecurity si chiama “Defense in Depth”. Occorre avere pazienza e costanza, e adottare le contromisure necessarie, in modo da poter vivere serenamente l’esperienza virtuale.