Vulnerabilità vere e presunte: un esempio

Una delle attività più complesse che un professionista della sicurezza informatica deve fare, soprattutto in un periodo come questo in cui siamo sommersi da informazioni e segnalazioni, è mantenere la capacità di ragionare.

Detta così sembra una banalità, e infatti lo è. Come tutte le cose banali però viene spesso accantonata, dimenticata e sacrificata in nome della fretta, del correre dietro all’ultima patch o di trovare una difesa appropriata all’ultima novità in campo hacker.

Purtroppo questa situazione è fin troppo spesso alimentata dai vendor, che approfittano dell’onda di emergenze, buzzword, articoli improvvisati ma con grande eco della stampa generalista, per vendere l’ultimo prodotto. Che spesso però non serve.

Facciamo un esempio di questa situazione, prendendo spunto da una notizia che si è sparsa parecchio negli ultimi giorni.

Si tratta di un nuova “vulnerabilità” di iOS, che permette di disabilitare il servizio Trova il mio iPhone. C’è anche un video che spiega bene come funziona

Detta così sembra ovviamente molto critica, visto che si tratta di una delle principali funzionalità di sicurezza fornite con iOS. E visto che la notizia ha avuto parecchia eco e grande diffusione sui social (come del resto tutte le notizie di sicurezza che riguardano prodotti Apple) è la tipica notizia che viene sfruttata per creare l’effetto FUD (avevo già parlato del rischio di questo effetto), e magari pubblicizzare il proprio prodotto di gestione di cellulari.

Perché dico sembra? Perché bisogna ragionare, e capire esattamente cosa abbiamo di fronte, e quali rischi reali stiamo correndo. Guardate il video. Come comincia?

Con un iPhone sbloccato.

Ora, ragionando con calma e lucidità (capacità che ogni esperto di sicurezza dovrebbe sviluppare e mantenere costantemente affilate), già questo punto annulla qualsiasi altra vulnerabilità.

Anche senza scomodare la gestione aziendale dei dispositivi mobili, il primo passo indispensabile per mettere in sicurezza il proprio cellulare è attivare il codice di sblocco. Tanto più che si tratta di un iPhone, dove c’è anche la comodità del Touch ID.

Già semplicemente vedendo il primo fotogramma del video abbiamo ridimensionato il tutto, visto che non ha senso parlare di altro, se un ladro che ruba il telefono può avere accesso a tutti i dati e impostazioni senza problema.

Cosa ci insegna questo esempio? Che tutto il rumore fatto da una notizia del genere, si basa su una carenza di sicurezza molto più grande e rischiosa. La vulnerabilità c’è, senza dubbio, ed è anche grave ma non ha senso vedere solo quella, quando si lascia il proprio smartphone alla disponibilità del primo che passa.

Questo esempio è indicativo del modo di ragionare che bisogna sempre mantenere, quello di capire i rischi reali e valutare il contesto. In ambito personale è sempre buona cosa farlo, ma nella sicurezza informatica aziendale è indispensabile ragionare in questo modo.

Anche perché non solo applicheremo un po’ di spirito critico che non fa mai male, ma risparmieremo un bel po’ di soldi per prodotti inutili che, come un caso come questo insegna, non avrebbe comunque risolto il problema di base.

Paperino e i perfidi hacker di Unknown

Nel numero di Topolino di questa settimana c’è una storia molto divertente, un po’ più divertente se siete degli appassionati della sicurezza informatica.

La storia è della serie di DoubleDuck (ovvero Paperino agente segreto di una organizzazione contro il crimine), e si intitola appunto Unknown.

Chi sono gli Unknown? Ma ovviamente un gruppi di hacktivist come dire…. anonimi… 🙂

Gli hacktivst di Unknown

Cliccate per ingrandire.

Molto divertente anche l’immagine dell’hacker che smanetta al computer naturalmente con la maschera di Guy Paper Fawkes.

Quello che è ancora più interessante per chi è del mestiere è l’articolo a corredo della storia che, giocando un po’ sui termini e sul significato in italiano, fa una bella panoramica sulle varie tipologie di smanettoni informatici.

Hacker Topolino

La cosa molto interessante è che l’articolo, ad opera di Barbara Garufi, è scritto insolitamente bene, non solo per una rivista di fumetti, ma anche per una qualsiasi testata giornalistica italiana.

Troppo spesso infatti i media mainstream fanno confusione tra hacker, cracker, hacktivist e criminalità organizzata.

In questo caso invece l’articolo mette subito in chiaro i confini e le distinzioni. E lo fa semplicemente, in poche righe e con concetti molto lineari.

Tipi hacker

L’articolo continua con la corretta classificazione dei vari tipi di hacker, messi più o meno in ordine di pericolosità.

Il modo è molto simile, anzi credo sia abbastanza ispirato, al lavoro fatto da Raoul Chiesa e ISECOM sull’Hacker Profiling Project, di cui è disponibile anche un ottimo libro.

La conclusione della carrellata è, correttamente, con il profilo più pericoloso di tutti, il cyber-soldato, la figura che ha più tempo, risorse e armi a sua disposizione.

Cyber-Soldier

Notevole anche qui come in poche righe si spieghi chiaramente lo scenario di cyber-warfare, attuale e reale, che molti quotidiani titolati ignorano o trattano con superficialità.

Anche la storia stessa, non vi svelo il finale, è impostata correttamente per far capire la psicologia di un hacktivist. Certo una persona che opera molto spesso oltre il confine legale, ma non è mai rappresentata come cattivo. Nella storia i villain sono altri, molto più pericolosi e legati alla malavita organizzata internazionale.

Addirittura alla fine c’è un piccolo colpo di scena che fa sembrare molto simpatici al lettore gli hacktivist di Unknown, seppur commettendo dei reati.

Insomma, una storia da leggere e conservare.

E da far leggere a chi vuole capire bene i complessi profili hacker, e non solo ai ragazzi.

Anzi, dovrebbero leggerla molti adulti e molti responsabili di servizi e sistemi IT.

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.

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.

Anatomia di un attacco via game server – Articolo su ClubHACK Magazine

ClubHack Magazione June 2012

Tra i tanti impegni lavorativi che mi allontanano un po’ dal blog c’è per fortuna tempo per scrivere qualcosa per gli amici della prima rivista indiana di haking.

L’articolo, intitolato Playing Bad Games: Anatomy of a Game-Server DDoS Attack, analizza la modalità di esecuzione di questo insolito attacco, che sta iniziando ad apparire in giro per la rete.

Potete leggere l’articolo in originale qui, scaricare il pdf della rivista (ci sono molte altre cose interessanti) leggere la traduzione italiana su questo blog!

Bye!