Come attivare l’autenticazione a due fattori su LinkedIn e Twitter

Avevo già parlato sia del perché sia molto importante utilizzare un sistema di autenticazione a due fattori per i servizi web, in particolare i social network, sia del fatto che i recenti attacchi a Twitter e LinkedIn potevano essere evitati (o per lo meno mitigati) proprio attivando questa funzionalità. Che su quei due social network però mancava.

Dopo qualche mese dagli attacchi, per fortuna sia Twitter che LinkedIn hanno reso disponibile ai propri utenti un sistema di verifica dei login.

Praticamente usano lo stesso metodo: registrate un numero di cellulare e loro vi inviano un SMS con un codice da usare dopo aver inserito username e password.

Vediamo meglio come abilitare questa funzionalità.

Twitter

Prima di tutto un consiglio: se avete già associato al vostro account Twitter un numero di cellulare rimuovetelo prima di attivare questo servizio. Sembra ci sia un bug, quindi si fa molto prima a togliere tutto e ricominciare da capo.

Abilitare il tutto è molto semplice, basta cliccare sull’ingranaggio in alto a destra, andare su Impostazioni, e selezionare l’opzione Richiedi un codice di verifica all’accesso

Twitter richiedi codice di accesso

Dovrete quindi inserire un numero di telefono cellulare, verificarlo inviando un SMS a Twitter, e successivamente potrete abilitare l’invio del codice

Twitter registra cellulare

Tutto abbastanza semplice.
Come già disponibile prima, inoltre, potrete selezionare quali avvisi ricevere sul vostro cellulare via SMS o se abilitare la funzionalità di SMS-twitting.

LinkedIn

Anche su LinkedIn la procedura è simile.

Riporto qui la versione inglese del sito, uso quella perché la versione in Italiano ancora non ha recepito gli ultimi cambiamenti grafici.

Basta cliccare sul proprio account in alto a destra, andare su Privacy and Settings –>Account –>Manage security settings e arrivare a questa schermata

linkedin-security-settings

Oltre a poter abilitare l’SSL (e fatelo immediatamente, anzi installate HTTPS Everywhere) potrete attivare la funzionalità di invio del codice di verifica.

Va quindi registrato un numero di cellulare, ed è fatta.

Linkedin registra cellulare

E ora?

E ora basta!

Da questo momento ogni volta che vi loggherete in questi due servizi con username e password vi verrà inviato un codice via SMS

codici sms

Ovviamente questo sistema non è esente né da rischi né da scomodità.

La scomodità principale è quella di avere copertura telefonica per ricevere, almeno in tempi brevissimi, l’SMS. E a volte, soprattutto all’estero, questo è un problema.

La speranza è quella che sia Twitter che LinkedIn seguano quanto fatto da Google e Facebook, utilizzando un generatore di codici all’interno magari delle loro app per smartphone.

In ogni caso è un primo passo, semplice ma molto importante, per essere un po’ più sicuri in rete su questi due servizi molto usati.

Bye!

Annunci

Autenticazione a due fattori – Perché è importante e come usarla

Trovate qui la traduzione italiana del mio articolo pubblicato sul numero 38 di ClubHACK Magazine.

La storia finora

Recentemente abbiamo letto notizie di due importanti attacchi a due altrettanto importanti social network: Twitter (del quale ho parlato qui) e LinkedIn. Questi attacchi erano mirati a rubare, dai due DB, username, password e addirittura token di sessione degli utenti dei due social network.

Molti hanno fatto correttamente notare che le password trafugate erano cifrate, ma questo non è sufficiente. Molti utenti infatti usano ancora password troppo comuni, in questo modo è semplice risalire, partendo da una password hashata, alla password in chiaro, giusto un giro veloce di rainbow table su un computer rapido.

Questo significa che cifrare le password non è più sufficiente, ma semplicemente perché usare solo le password non è più sufficiente.

Se un attaccante ruba un database di password di Twitter o LinkedIn, significa che può accedere con un gran numero di account, questo principalmente perché questi due social network molto importanti non dispongono di una caratteristica di sicurezza fondamentale: l’autenticazione a due fattori.

Questa caratteristica è davvero fondamentale perché username e password sono troppo deboli, troppo facilmente rubabili, e addirittura troppo facilmente indovinabili, anche senza essere hacker esperti.

Così è importante che quando ci si connette ad un servizio web, soprattutto un social network che tratta nostri dati molto importanti, bisogna usare non solamente qualcosa che noi sappiamo (come la password) ma anche qualcosa che si possiede.

Questo tipo di caratteristica tipicamente funziona aggiungendo alla coppia username e password un token, hardware o software, come questo SecurID di RSA.

screenshot.2

Questo significa che se noi abbiamo questo token, siamo gli unici che possiamo accedere al servizio. Possiamo farlo perché un attaccante può ancora rubare o indovinare la nostra password dal database del social network, ma dovrebbe anche rubarci dalla tasca il nostro token. E questo è improbabile.

Come detto prima, né Twitter né LinkedIn offrono un’autenticazione a due fattori. Di sicuro ci stanno lavorando, ma ci vorrà un po’ di tempo prima che possano renderla disponibile ai propri utenti.

Tuttavia altri social network e servizi cloud già oggi offrono questo tipo di autenticazione. Stiamo parlando di Facebook, Google e Dropbox.

Vediamo come impostare l’autenticazione a due fattori su questi servizi, e rendere i nostri account più sicuri.

Facebook

L’autenticazione a due fattori su Facebook funziona in due modalità. Può sia inviare un SMS al vostro cellulare, contenente il token da utilizzare nella fase di login, sia generare lo stesso token dall’applicazione di Facebook del vostro smartphone. Prima però è necessario abilitare la funzionalità. Vediamo come.

Prima di tutto dovete andare nel tab Sicurezza del menu Impostazioni Account, e troverete questa opzione

screenshot.3

Vi sarà chiesto di inserire e validare il vostro numero di cellulare ed è fatta! Da questo momento ogni volta che farete login da un nuovo browser, o se avrete cancellato i cookie dal vostro solito browser, Facebook vi chiederà di inserire il codice inviato tramite SMS al vostro cellulare.

In alternativa, se avete uno smartphone con l’app di Facebook, potrete ottenere un codice valido tramite l’opzione Generatore di Codici presente nell’app stessa (funziona molto bene sia su Android che su iOS).

Google

La funzionalità di autenticazione a due fattori di Google funziona in modo molto simile a quella di Facebook.

Per attivarla dovete andare nella pagina delle Impostazioni del vostro Google Account, tab Sicurezza e abilitare la Verifica in due passaggi

screenshot.4

Vi sarà richiesto di inserire il vostro numero di cellulare e confermarlo

screenshot.5

Fatto questo potrete accedere al vostro Google Account solo inserendo il codice inviato via SMS al vostro cellulare.

Questa è la modalità principale, analogamente a Facebook anche Google mette a disposizione un’app da scaricare sullo smartphone, la Google Authenticator.

Si può scaricare da iTunes o Play Store, è gratis ed è molto semplice da configurare, poiché per attivarla dovete solo inquadrare il QR Code che Google vi mostra nella pagina di attivazione dell’app

screenshot.8

La caratteristica più interessante di Google Authenticator è che non è legata ad un singolo account, è possibile infatti utilizzarla per più Google Account, e metterli in sicurezza tutti in una sola volta. Questo perché l’app genererà un codice per ognuno degli account a cui è associata.

La cosa ancora più interessante è che questo servizio non è valido solo per Google, ma può essere utilizzato come framework per fornire un’autenticazione a due fattori anche da altri servizi cloud, come ad esempio Dropbox.

Dropbox

Per mettere in sicurezza il vostro account Dropbox con l’autenticazione a due fattori, fornita da Google, dovete andare nel tab Security del menu Settings, ed abilitare la two-step verification

screenshot.10

Vi sarà quindi chiesto di inserire un numero di telefono, dove mandare l’SMS col codice, o in alternativa utilizzare un’app per generare il codice di accesso.

screenshot.12

Tutto qui! Ora aprendo l’app Google Authenticator avrete questa situazione

screenshot.13

Conclusioni

Abbiamo visto un po’ più in dettaglio cos’è l’autenticazione e due fattori, perché è importante averla disponibile sui servizi che si utilizzano e, cosa più importante, come è facile attivarla ed usarla.

Sfortunatamente non tutti i social network che usiamo quotidianamente offrono questa funzionalità, ma per stare più sicuri è importante attivarla ogni volta che ci viene offerta.

Può essere noioso inserire ogni volta un codice, ma questo piccolo passaggio può realmente migliorare la nostra sicurezza online.

Aggiornamento: visto che anche LinkedIn e Twitter hanno abilitato la funzionalità di autenticazione a due fattori, ho scritto una guida per abilitarla.

Federico Filacchione
pubblicato originariamente come “Two Factor Authentication – Why it is important and How to use it” su ClubHACK Magazine numero 38.

Cos’è e come si gestisce il Social Risk

Questo articolo esce in crosspost con il blog Marketing Consumer, dove lo stesso tema è affrontato dal punto di vista della protezione dell’immagine dell’azienda, e fa parte della serie Spiegare la sicurezza.

Ho recentemente partecipato al Security & Risk Management Summit di Gartner. Tra i vari temi del convegno si è trattato anche di come le aziende debbano sempre di più occuparsi del social risk. Cioè di quanto le discussioni circa l’azienda sui social network possano provocare danni, anche molto gravi, all’immagine, al fatturato e alla sicurezza dell’azienda stessa.

La buona notizia è che ci sono gli strumenti per difendersi, come definire un’efficace social media policy, identificare un responsabile della social compliance e mettere in campo una squadra di marketing d’emergenza.

Questo argomento è particolarmente interessante perché riguarda non solo le strategie di marketing che un’azienda moderna deve mettere in pratica per difendersi, ma anche e soprattutto l’analisi e la prevenzione dei rischi. E, tanto per contestualizzare, il rischio principale di cui stiamo parlando è quello dell’hacktivism.

Sono stati portati diversi esempi, anche con testimonianze dirette di aziende, sui vari aspetti dell’interazione tra una società e il mondo dei social network. Si è passati da sensibilizzare i dipendenti a come proteggere la propria privacy (e di riflesso l’immagine dell’azienda), a come attivare delle policy corrette per gestire un grande evento.

Il caso più emblematico presentato è stato quello del CIO durante le ultime Olimpiadi di Londra, che non solo ha spinto gli atleti ad usare i social network definendo policy opportune (qui il documento dettagliato), ma le ha anche applicate duramente, laddove si siano verificate delle violazioni che potevano compromettere l’immagine delle Olimpiadi.

Quello su cui vorrei focalizzare l’attenzione è tuttavia una problematica molto particolare, ovvero come gestire le emergenze di comunicazione e marketing che possono emergere quando esplode un “incidente” sui social network, e in seguito sulla stampa mainstream.

Partiamo dall’inizio.

È sempre successo che possa arrivare, dall’interno o dall’esterno, un evento che possa nuocere all’immagine dell’azienda o del brand. Magari questo incidente viene poi ripreso dalla stampa e causa problemi o danni gravi per cui deve intervenire il reparto di public relations.

La gravità di questo incidente può aumentare se l’azienda lega molto la sua immagine o le sue azioni a concetti di tipo etico. Ad esempio se siete una compagnia petrolifera che si autodefinisce “green”, e poi vi beccano a trivellare un parco nazionale in Nuova Zelanda, allora la gente potrebbe reagire molto male. E come reazione intendo arrivare a concordare un’azione che possa provocare danno alla sicurezza dell’azienda, ai suoi dati riservati ed all’immagine dell’azienda sul web e sui media. Per esempio con un bel defacement.

Ora questo come fa a peggiorare con i social network? Perché nei gruppi online prima, e nei gruppi di Facebook e similari dopo, si concentra un’enorme quantità di energia. L’energia cresce perché in questi gruppi di persone, anche molto ampi, parlano costantemente del “nemico”. Ne parlano e non vedono l’ora di avercelo davanti. E il nemico può essere la multinazionale petrolifera, se il gruppo è di ambientalisti, o una qualsiasi azienda che ha a che fare con gli animali, se il gruppo è di animalisti, come in seguito.

Questa energia, se scatenata in seguito ad un incidente, provoca una reazione a catena enormemente più potente rispetto al normale flusso di eventi che veniva generato con il semplice intervento della stampa. Perché non dimentichiamocelo, stiamo nel mondo del Web2.0, dello user generated content. E perché le cose che avvengono su internet, oggi, restano lì per sempre.

Ed è proprio questa caratteristica a cambiare le carte in tavola e a richiedere interventi eccezionali e tempestivi.

Esaminiamo quindi un caso reale, citato al convegno, che illustra molto bene la tempistica di questi eventi. E insegna quali sono gli errori da evitare.

Alcuni di voi ricorderanno del negozio Petland di Akron, Ohio.
Petland è una catena in franchising di negozi di animali che puntava ad apparire particolarmente attenta alla cura dedicata ai piccoli amici domestici.

Il 29 luglio del 2009 una dipendente del negozio Petland di Akron  lascia due conigli maschi nella stessa gabbia, violando le politiche aziendali e la mission dell’azienda. Gli animali iniziano a picchiarsi selvaggiamente, tanto che la dipendente è costretta ad annegarli per evitare che muoiano di dolore dalle orribili ferite che si sono provocati. Ma la cosa più grave non è questa squallida e triste vicenda, quanto il fatto che la stessa ragazza posta sul suo profilo Facebook una foto sorridente tenendo gli animali morti come trofeo.

Questo evento scatena una serie di eventi riassunti in questo schema:

Akron Petland Incident Timeline

Fonte: Gartner

Il giorno dopo un amico su Facebook della ragazza segnala la cosa alla Humane Society, e successivamente alla PETA. La PETA chiede chiarimenti a Petland, che non considera adeguatamente la vicenda e non risponde alle richieste dell’organizzazione. Cinque giorni dopo la PETA chiama, utilizzando i social network, tutti i suoi iscritti all’azione e alla protesta contro il negozio di Akron e tutti gli altri negozi Petland degli Stati Uniti.

Otto giorni dopo la pubblicazione della foto Petland chiude il negozio di Akron, licenziando tutti i dipendenti (che passeranno i loro guai personali).
Trovate dettagli sulla vicenda, e la brutta foto della ragazza, sul sito ufficiale PETA.

Questo non è solo un case study molto utile a comprendere la potenza dell’energia racchiusa nei social network, ma anche un esempio dei danni che questo tipo di incidenti può portare ad un’azienda. Sì perché oltre a perdere un negozio, Petland ha avuto al sua reputazione distrutta, con danni che seguono ancora adesso.

Provate a cercare “Petland” su Google Immagini:

Ricerca Petland su Google Immagini

Ancora oggi compare la foto incriminata e la terza immagine, una di quelle più visibili, è di persone con cartelli “Petland uccide i cuccioli“.
Chi si affiderebbe ad un’azienda così, ora?

E tutto questo solo per non essersi accorti di un fatto molto grave, e soprattutto per non aver risposto pubblicamente e tempestivamente. E il motivo è semplice: l’azienda non aveva una social media policy per i dipendenti (la ragazza nemmeno pensava che la sua azione l’avrebbe portata a perdere il lavoro), non effettuava un monitoraggio dell’andamento del brand sulla rete, e non aveva un flusso di gestione della segnalazione proveniente da un gruppo di attivisti.

Questa brutta vicenda si è conclusa qui. Ma se il caso fosse stato ripreso da un gruppo di attivisti hacker, un gruppo anonimo ad esempio. E se questi avessero attivato subito una #op-petland su tutti i network? Ci sarebbero stati defacement sui siti aziendali, furto di informazioni e chissà quante altre cose, magari molto riservate, sarebbero uscite fuori…
E il danno sarebbe stato anche più grave che chiudere un negozio, il rischio era di chiudere tutta la baracca.

Vi chiedere come sia possibile difendersi da questo tipo di incidenti? Non è possibile. Avverranno sempre, e sempre più spesso dato l’enorme numero di persone in tutto il mondo che usa e userà i social network.

È possibile però mitigare il rischio, attraverso un’attenta gestione degli eventi.

Al fine di ottenere questo risultato sono è necessario un cambiamento di mentalità dei settori marketing e public relations dell’azienda, e l’introduzione di due figure fondamentali: il vice presidente della Social Compliance e il team di marketing di emergenza.

Il ruolo del VP Social Compliance (e pongo parecchia attenzione sulla qualifica di vice presidente, indice di quanto alto deve essere il commitment dell’azienda) è quello di definire le social media policy, da applicare sia internamente che esternamente. Definire le politiche di utilizzo vuol dire trasmettere al consumatore, cliente dell’azienda o più in generale un suo stakeholder, un’immagine coerente ed efficace del brand aziendale. Include sia formare degli operatori che alimenteranno i contenuti sui social network utilizzati, sia definire qual è il messaggio che l’azienda vuole trasmettere al suo pubblico e come farlo. Questo implica anche sensibilizzare i dipendenti sull’uso dei social network poiché potenzialmente dannoso per l’immagine dell’azienda. Questo avviene principalmente mostrando come impostare i livelli di privacy e come e cosa dire se non si vuole rischiare di creare danni. Molte persone nemmeno si rendono conto di quanto espongono pubblicamente, e quanto possono danneggiare non solo l’immagine aziendale, ma anche la propria.
Cosa ancora più importante, deve monitorare, mediante tecniche di sentiment analysis, l’andamento del brand aziendale sui gruppi internet. Solo in questo modo potrà identificare prontamente dei potenziali eventi pericolosi per l’immagine aziendale, e potrà definire le strategie di risposta per la gestione del rischio.

Una volta identificato un focolaio di rischio, è necessario che il responsabile della social compliance faccia intervenire il team di marketing d’emergenza, ovvero una squadra di professionisti delle pubbliche relazioni e della pubblicità addestrati a gestire situazioni di questo tipo. Loro interagiranno con le persone che hanno iniziato l’incidente, rispondendogli, indagando su cosa realmente è successo e fornendo il prima possibile una versione ufficiale dell’azienda sulla vicenda in questione.

Solo in questo modo sarà possibile non evitare che si inneschi un incidente, ma gestirlo e ricondurlo subito sotto il controllo dell’azienda. Questo per cercare di dominare il possibile rischio, e non subirlo.

Ovviamente potrebbe non bastare ad evitare una #op-qualcosa. Quindi è essenziale che il responsabile della comunicazione interagisca con il CISO dell’azienda, per allertare tutte le strutture di analisi degli eventi, di intelligence (OSINT, anyone…) e di prevenzione degli attacchi, al fine di monitorare attentamente la situazione.

Perché come dice il motto di questo blog: “l’unica cosa che puoi fare è accorgertene e rispondere”. E aspettarsi una cosa facilita senza dubbio il tutto.

Certamente questo tipo di organizzazione aziendale richiede molte risorse e molta maturità da parte dell’azienda, ma sta diventando praticamente obbligatorio per tutte le aziende esposte, per un motivo o per un altro, all’attenzione di gruppi di attivisti sui social network. Il rischio aumenta ovviamente con l’aumentare della dimensione dell’azienda.

C’è da dire che ci sono diversi documenti da cui trarre ispirazione. Il sito Social Media Governance propone un ben fornito database di policy già definite da alcune delle più grandi aziende del mondo. Basta capire qual è il ramo industriale della propria azienda e si può tranquillamente trarre ispirazione.

Tutte le società dovrebbero inoltre (e molte già lo fanno) usare tecniche di sentiment analysis per monitorare l’andamento dei propri brand sulla rete. Solo che questo monitoraggio va esteso dal semplice controllo delle campagne di marketing, anche alla difesa dell’immagine e degli asset dell’azienda stessa, va ampliato introducendo tecniche di Open Source Intelligence e va costantemente analizzato non solo dal reparto marketing, ma anche da quello della sicurezza IT.

Perché l’importante resta sempre dare una risposta all’utente arrabbiato o deluso. E la risposta deve arrivare il prima possibile, deve essere puntuale e onesta.

Altrimenti non si potrà evitare la deflagrazione dell’energia dei social network, e si rischia di bruciarsi davvero.

Bye!

Giocare sporco: anatomia di un attacco DDoS tramite game server

Trovate qui la traduzione italiana del mio articolo pubblicato sul numero 29 di ClubHACK Magazine.

Gli attacchi di tipo Distributed Denial of Service (DDoS) sono l’arma più comune e facile da utilizzare per creare grossi problemi e danni molto visibili ad un determinato bersaglio, e con uno sforzo molto limitato.

Questo attacco è senza dubbio quello più utilizzato dai gruppi di hacktivist, poiché necessita di un tool molto comune (come LOIC), e si basa sulla rabbia di centinaia, se non migliaia, di persone disposte a fare qualcosa di semplice. La sua efficacia deriva anche dal fatto che è un attacco molto complesso da evitare, questo perché gli attaccanti dispongono di una banda di rete enorme, e c’è poco altro da fare se non chiudere i firewall per evitare danni peggiori ai server interni. In ogni caso l’attaccante vince, e i servizi sono giù per un po’ di tempo.

Questo è l’unico lato positivo della storia, l’attacco non può durare a lungo e il “Tango Down“, se correttamente individuato e mitigato con una chiusura completa, durerà pochi minuti, lasciando il tempo a chi l’ha sferrato di bullarsi con il resto del mondo via Twitter.

Devo ammettere che spesso si assiste a società in grado di farsi un attacco DDoS da sole,  pubblicando servizi su server mediocri e con un’architettura di rete ridicola. Così non appena il sito va online tutto viene giù alla prima milionata di richieste della homepage. E questo causa molti più problemi che non un gruppo di hacktivist, non credete? 🙂

Tornando all’argomento dell’articolo, questo è il modo classico di eseguire un attacco DDoS, ci sono però altri metodi, più interessanti da analizzare e più raffinati, per creare questo tipo di disservizi.

Lavorando sul campo svolgo spesso analisi post-mortem su attacchi di vario tipo, e recentemente ho analizzato questa modalità di eseguire un DDoS tramite server di gioco online. Vediamo insieme come.

Partiamo dal dire che l’attacco non è eseguito direttamente dall’attaccante, ma usando, come fossero una botnet, un numero elevato di game server custom (cioè gestiti non dalla casa produttrice del gioco, ma da gruppi di fan, spesso illegalmente), sparsi per il globo. Sono loro che attaccheranno il bersaglio.

La Figura 1 mostra come l’attacco è eseguito:

Game server DDoS Attack Flood Scheme

Schema del flood DDoS tramite game server

La prima cosa che colpisce è che, tenendo presente che i game server custom possono essere dislocati ovunque nel mondo e che nascono e muoiono in continuazione, è praticamente impossibile identificare il reale attaccante.

Questo tipo di attacchi non è molto conosciuto, né molto eseguito, ma è stato individuato e descritto per la prima volta lo scorso anno.

Ma perché succede una cosa simile?
Succede perché questi server di gioco sono vulnerabili ad un attacco specifico. L’attacco viene eseguito chiedendo, con un pacchetto fatto ad hoc, lo status di gioco del server. Questa è una richiesta UDP molto piccola, ma se fatta spoofando l’IP sorgente del richiedente, il server risponde a quell’IP con un’enorme quantità di informazioni.

Sempre lo scorso anno uno degli sviluppatori di questi server custom ha pubblicato questa vulnerabilità, e contestualmente rilasciato una patch per risolvere il problema. Naturalmente in molti casi questi server sono del tutto illegali, il software è scaricato chissà da dove, e sono attivi in molte nazioni, comprese Russia e Cina. Non ci si può quindi aspettare che gli amministratori siano molto attenti ad applicare le ultime patch, o che rispondano a qualunque tipo di richiesta. Molto probabilmente chiuderanno bottega e ne attiveranno uno nuovo da un’altra parte.

Avendo modo di lavorare direttamente al caso, posso pubblicare i dettagli dell’attacco, analizzando il traffico reale. Come potete facilmente immaginare, non pubblicherò il bersaglio dell’attacco, né i nomi o gli IP dei game server coinvolti. Questo è solo un case study per capire come funziona questo tipo di performance.

La prima cosa da notare è la tipologia dei pacchetti. Come detto è tutto traffico UDP, di dimensione variabile, inviati alla porta 21 del server oggetto dell’attacco.

Fusso UDP di risposta

Fusso UDP di risposta

Guardando il dettaglio di un paio di flussi, possiamo vedere che il pacchetto è uno statusResponse da un server custom di Call of Duty.

CoD statusResponse

CoD statusResponse 2

Potrei continuare a mettere screenshot per giorni, i server coinvolti nell’attacco erano centinaia, e ognuno aveva inviato un’enorme quantità di risposte. Immagino che i giocatori non fossero molto contenti dei lag nel gioco durante l’attacco!

Call of Duty non è stato l’unico gioco utilizzato, ma erano coinvolti anche dei server Quake 3.

Quake3 game server resposne

E anche in questo caso abbiamo un pacchetto statusResponse.

Quake 3 response

Penso che sarete d’accordo con me nel ritenere questo attacco molto più raffinato e ordinato, rispetto ad un classico DDoS eseguito con LOIC.

Vi domanderete ora come fare ad evitare questo tipo di attacchi.
C’è poco da fare purtroppo.

Mettere in blacklist i game server è una tattica poco efficace, loro e i loro IP vanno e vengono ogni giorno, quindi non servirebbe a molto. Proseguendo con il patching questo tipo di vulnerabilità potrebbe andare a morire, ma ci saranno sempre server vulnerabili in giro, spesso da certe nazioni, pronti ad essere usati per sferrare questi attacchi.

Come al solito la migliore difesa monitorare costantemente cosa accade sulla vostra rete. Solo in questo caso è possibile rispondere rapidamente e provare a mitigare l’attacco, sia tramite blacklist temporanee, sia tramite chiusure dei firewall.

Ma, come al solito, se non vedete nulla non saprete mai cosa sta succedendo.

Federico Filacchione
pubblicato originariamente come “Playing Bad Games: Anatomy of a Game-Server DDoS Attack” su ClubHACK Magazine numero 29.

Una panoramica sulla Cloud Forensics

Trovate qui la traduzione italiana del mio articolo pubblicato sul numero 4 di Hakin9 Extra.

Introduzione

Il cloud computing è senza dubbio una delle grandi innovazioni dei nostri tempi. Introduce un nuovo modo per implementare architetture complesse che solo dieci anni fa sarebbero costate centinaia (se non migliaia) di volte tanto.

Questo è avvenuto sia per l’introduzione della virtualizzazione delle risorse, dovuta all’elevato potenziale dei moderni computer, sia per una nuova più scalabile e flessibile organizzazione dei servizi offerti, orientati più verso un modello di business orientato ai Servizi stessi e non al Software.

Tutto ciò, insieme ad un nuovo modo di usare le applicazioni (tramite un browser, e non con il vecchio paradigma client-server), ha introdotto ciò che il NIST descrive come:

Un modello per abilitare un accesso pratico, on-demand via rete ad un gruppo di risorse condivise e configurabili (ad es. reti, server, storage, applicazioni e servizi), che può essere rilasciato rapidamente, con una minima gestione o interazione col provider.

Ci sono tuttavia dei problemi portati da queste innovazioni. Il principale è che tutti i modelli tradizionali, non ideati in tempi di cloud, devono essere ripensati.

Uno di questi modelli è appunto la computer forensic. Come fare questo tipo di attività su sistemi in the cloud, e come interagire correttamente con i provider di servizi cloud.

In questo articolo cercheremo di fare una panoramica su quali sono le nuove sfide che un professionista della forensic deve superare per fare bene il proprio lavoro, e cosa chiunque usi un servizio cloud, o ne gestisca uno, deve tenere in mente per evitare questo tipo di problemi nel futuro.

Cosa è cambiato?

Perché ci sono queste nuove sfide? Vediamo cosa è cambiato nel cloud.

Il modello della forensic tradizionale è basato su:

  • Raccogliere le evidenze on-site.
  • Rispettare la legge, e garantire la catena di custodia.
  • Analizzare i dati per trovare evidenze, eindividuare le prove.

Questo, nel cloud, cambia completamente.

Non esiste un sito fisico. Già, avete letto bene. “Nel cloud” non c’è un posto dove si può andare e sequestrare un pc o un server per analizzarlo in seguito. Nel cloud ci sono numerosi CED che ospitano contemporaneamente i dati che state cercando.
Questo è veramente un incubo, anche perché siamo al primo passo e già sembra un ostacolo insormontabile.
Considerato che l’architettura cloud consiste nella condivisione dei dati, risorse e servizi su diversi CED, infrastrutture virtualizzate e servizi aperti a chiunque, non c’è modo di essere certi che i dati necessari siano stati raccolti completamente.

Non c’è una singola legge. Garantire la catena di custodia significa che bisogna rispettare leggi specifiche, di una nazione specifica (in genere la vostra). Ma nella prospettiva del cloud non c’è una singola nazione. Una rete diffusa di centri di elaborazione dati significa una rete diffusa di giurisdizioni. E questo significa che può essere molto complesso (in alcuni casi, volutamente, impossibile) interagire con nazioni che non hanno leggi moderne sulla criminalità informatica.

Non c’è un singolo provider. Analizzare i dati significa che tutto quello che è stato raccolto deve essere coerente e può essere usato come prova. Ma se i servizi cloud che state analizzando sono relativi ad un’altra infrastruttura, potete garantire di non aver perso nulla? E chi vi può fornire ulteriore assistenza?
Questo è un problema reale già ora, facciamo un esempio. C’è un servizio molto noto che permette di sincronizzare e condividere file su diversi computer e dispositivi. Basta inviare, o meglio “droppare” un file in una cartella, o un “box”, e sono disponibili ovunque. Ora questo servizio di cloud utilizza risorse di un altro servizio sempre di cloud, di più altro livello, gestito da una nota libreria online di una “femmina cavallerizza”… La domanda ora è chi comanda? Chi realmente gestisce questo sistema? Difficile rispondere.
La risposta è che, dopo aver affrontato diverse giurisdizioni, la sfida qui è capire cosa quei dati significano, e cosa le due entità coinvolte sanno di quei dati e possono darvi. E questo può essere molto difficile.

Quindi è tutto così complicato? No, non tutto.

Poiché il modello cloud è una grande opportunità per tutti, può essere una grande opportunità anche per i professionisti della forensic. Questo però significa che anche i provider di servizi cloud devono essere pronti a confrontare i loro sistemi con le nuove sfide presentate dal nuovo modello.

Molti provider cloud non sanno cosa dire quando è il momento di parlare di cloud forensics, questo perchè fondamentalmente loro non conoscono il problema. Non se ne occupano perché il modello cloud è troppo veloce, scalabile e ampio per avere a che fare con questo tipo di problemi, strettamente legati al modello passato.

Ma questo è sbagliato in molti sensi. È sbagliato per il cliente, perché se succede qualcosa (e qualcosa prima o poi succederà) vi ritroverete in un gran guaio. È inoltre ancora più sbagliato per il cloud provider stesso, visto che è lui il responsabile di quello che succede sui suoi sistemi e sui servizi che offre. Questo quando le cose vanno bene, certo, ma ancora di più quando le cose andranno male.

Il cybercrime non sta a guardare

Finora abbiamo parlato di servizi regolare. Ma come è facile immaginare, il modello cloud non è un modo efficiente di fare business solo per le aziende normali, è un ottimo modello anche per i criminali.

Questo crea una notevole minaccia per chiunque gestisca un servizio cloud. E la minaccia è doppia.

Il primo problema è che potreste scoprire che il vostro servizio (lecito) è usato da cybercriminali per fare cose illegali. Ad esempio ci sono numerosi riscontri sul fato che qualche servizio online di malware scan è usato da chi scrive il malware per dimostrare la bontà del loro prodotto. È come se dicessero: vedete? Nessuno lo riconosce, comprate il mio malware!
Questo è un usonon proprio lecito di uno strumento perfettamente legale, ma magari tra qualche tempo i tizi vestiti di blu potrebbero fare un salto da voi e chiedervi “cosa sta succedendo?”.

L’altra minaccia è che anche i criminali stanno attivando i loro servizi nel cloud. Oggigiorno ci sono una quantità enorme di toolkit per produrre “malware fatto in casa”, e si possono acquistare per pochi dollari. La cosa interessante è che questi prodotti vengono venduti, supporto incluso (sì, c’è anche un helpdesk per usarli), su infrastrutture praticamente uguali a al modello diffuso di software-as-a-service (SaaS).
Ma quando un sistema come questo viene bloccato e, magari, sequestrato, come fa un professionista della computer forensic a capire cosa stava succedendo lì sopra? Come può estrarre i dati necessari a provare il crimine?

Questi sono casi reali, come reali sono le sfide che pongono.
E poi, pensateci, non è anche una botnet un “servizio cloud”? 🙂

Opportunità

L’abbiamo detto prima e lo diciamo ancora: siate pronti. Questo è un problema molto importante, e non deve essere sottovalutato.

Questo significa anche che molti professionisti della computer forensic possono realmente aiutare a implementare strumenti e strategie di cloud forensics nei nuovi servizi. Poiché questo è un problema che ogni cloud provider dovrà affrontare prima o poi, questa è un’eccellente opportunità per fornire supporto a definire una strategia della cloud forensics.

Il paradigma cloud è talmente versatile che è possibile, e infatti ci sono già dei progetti in tal senso, sviluppare una piattaforma di forensic-as-a-cloud-service, fatta specificatamente per il cloud.

Se siete un provider, può essere una grande opportunità anche per voi, perché definire una strategia e un’architettura per la cloud forensics significa implementare quegli strumenti e quelle procedure nei vostri servizi cloud, e questo è quello che va fatto ora. Questo significa sia una raccolta di dati proattiva, basata su strumenti di computer forensic (sì, anche quelli standard attuali!), sia una dettagliata procedura di incident response che includa la forensic, sia infine un addestramento per il vostro staff al fine di fargli comprendere meglio i rischi del nuovo modello (questo passo, sinceramente, è valido in ogni caso).

Tutto ciò significa anche comprendere le leggi delle nazioni dove sono i vostri CED. E questo è importante non solo per essere pronti in caso di incidente, ma anche per evitare possibili procedimenti legali nel caso le leggi siano troppo stringenti.

Negli Stati Uniti, ad esempio, molti tribunali e molti giudici stanno chiedendo sempre di più prove e dati provenienti dai sistemi informatici. E chiedono come le prove sono state raccolte, come sono state conservate ed analizzate.

E se siete voi l’azienda alla sbarra, e non sapete rispondere alla domande del giudice, potreste incorrere in sanzioni, o peggio.

Per concludere: non aspettate il vostro turno per finire nei guai, preparatevi.

Federico Filacchione
pubblicato originariamente come “An Overview on Cloud Forensics” su Hakin9 Extra numero 4/12© Software Press, Poland.