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.

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.

Proteggi la tua privacy online con Tor

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

Tor logo

Che cos’è Tor?

Iniziamo con spiegare cosa significa Tor: è un acronimo che sta per The Onion Router (Il Router Cipolla).
Un router è un dispositivo che gestisce e smista il traffico su una rete di computer. Quando scrivere una URL nel vostro browser, come http://chmag.in e date invio, inviate questa richiesta al router del vostro ISP, che la rigirerà ad un altro router esterno e così via, finché non raggiungete il router dell’ISP di CHmag, che vi invierà la pagina del sito. Ognuno di questi passaggi è chiamato tecnicamente un hop.

Tor funziona esattamente come questo sistema di router, però poi c’è la cipolla. Beh, la cipolla è… una cipolla! 🙂
La ragione per cui gli sviluppatori di Tor hanno usato questa metafora è che quando si usa il sistema di routing di Tor, i dati vengono inviati all’interno di diversi livelli di cifratura, esattamente come passare tutti gli strati di una cipolla!

La pagina di Wikipedia di Tor ha un’eccellente immagine che spiega il funzionamento.

TOR The Onion Network

Electronic Frontier Foundation “How Tor Works” – licensed CC Attribution 3.0

Ma c’è un sacco di gente lì dentro! Non dovrebbe difendere la mia privacy?

Può sembrare strano ma così si difende la privacy.

Prima di tutto, quando si usa il tradizionale sistema di router, la richiesta passa lo stesso attraverso un numero di hop, ma in più può essere intercettata, letta e modificata. Questo perché chi controlla quell’hop può vedere la richiesta inviata, e sapere cosa stava cercando chi l’ha inviata.

All’interno del network tor questo non può succedere. Poiché il percorso è scelto in maniera casuale ogni hop può solamente decifrare il piccolo livello cipolla di cifratura che gli compete, e poi passare al seguente salto.

Come si può vedere dall’immagine sopra solo l’ultimo passaggio è in chiaro, dal cosiddetto nodo di uscita fino al web server di destinazione. Questo è necessario perché l’ultimo nodo deve necessariamente conoscere il destinatario della richiesta e cosa chiedere. Ma la privacy di chi ha fatto la richiesta è comunque protetta, visto che anche sniffando (cioè intercettando i dati inviati sulla rete), il nodo di uscita non può sapere chi ha fatto la richiesta, quindi nessuno può identificarvi. Il server di destinazione vedrà solo l’indirizzo IP, che identifica univocamente ogni dispositivo sulla rete, del nodo di uscita.
Il funzionamento è molto più semplice di quanto sembri, lo vedremo tra poco.

Poiché l’uso di Tor è assolutamente gratuito, ogni utente che si connette diventa un membro della rete e contribuisce a passare “cipolle” su e giù di continuo. Ma non c’è da preoccuparsi, nessuno è obbligato a funzionare da nodo di uscita, è possibile farlo ovviamente, ma questa opzione deve essere abilitata volontariamente.

Sembra molto complicato… non sono un hacker! Non posso usarlo!

In effetti sì, il progetto Tor è veramente molto complesso nel suo funzionamento. Gli sviluppatori hanno tuttavia fatto, e continuano a fare, un lavoro eccellente di semplificazione nell’utilizzo dello strumento, e lo hanno reso accessibile a chiunque, in modo estremamente semplice.

Tor ha infatti un sotto-progetto chiamato Tor Browser Bundle. Il software non richiede installazione e permette di navigare in sicurezza con un semplice clic. Non essendo necessario installarlo è semplice da trasportare su una chiavetta USB, in modo da averlo disponibile su ogni sistema che utilizzate, sia il proprio pc, un hotel, un internet cafè o il computer dell’ufficio.

L’unica cosa da fare è scaricarlo dalla pagina del progetto, è disponibile anche una versione italiana e c’è per Windows, Mac OS X o Linux.

Una volta scaricato e scompattato l’archivio .exe avrete questa serie di icone

Tor Browser Bundle

A questo punto manca solo un clic dal navigare sicuro. Basta far partire “Start Tor Browser.exe” e Tor inizierà a connettersi alla rete protetta.

Nel giro di pochi secondi vedrete questa finestra:

Vidalia Control Panel

Non dovete preoccuparvi di tutti i bottoni e le funzioni all’interno del pannello di controllo di Vidalia, l’unica cosa che conta è la cipolla verde e le parole “Connesso alla rete Tor!“. Questo significa che ora siete protetti.

Ma la magia di questo strumento non finisce qui. Non appena stabilita la connessione con la rete Tor una versione speciale di Firefox, inclusa nel pacchetto, si aprirà automaticamente con questa schermata:

Firefox Tor Portable

Questo vuol dire che è tutto finito! Usando questo Firefox navigherete automaticamente all’interno della rete Tor, in modo del tutto anonimo e sicuro. Volete provare? Andate su http://whatsmyip.net sia dal Firefox incluso nel Tor Bundle sia dal vostro brower classico, e vedrete che gli indirizzi IP sono diversi. Questo significa che state usando l’IP del nodo di uscita, come spiegato in precedenza. Quando non vorrete più usare Tor, basta chiudere la finestra di Firefox, si chiuderà anche il pannello di controllo di Vidalia e la connessione alla rete Tor terminerà.

In conclusione, avete visto che è molto semplice usare Tor. D’ora in poi, se volete proteggere la vostra privacy online, non dimenticatevi di usare Tor Browser, e portatelo sempre con voi, specialmente su postazioni che non conoscete.

Proteggersi non è così complicato come sembra, anzi non è complicato per nulla! Basta seguire dei semplici passaggi ed è fatta. Questo è solo l’inizio di molti altri servizi che sono disponibili all’interno del progetto Tor, ma questo passo è quello che vi serve per navigare protetti.

Buona privacy e navigazione tranquilla a tutti!

Federico Filacchione
pubblicato originariamente come “Protect your privacy online with ’TOR” su ClubHACK Magazine numero 26.

CAPTCHA, cosa sono e come usarli

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

Introduzione

CAPTCHA è un acronimo per Completely Automated Public Turing test to tell Computers and Humans Apart. Il test è stato creato nel 2000 da alcuni ricercatori della Carnegie Mellon University, per prevenire l’utilizzo illecito di strumenti come i bot nella fase di registrazione ad un servizio web. Il principale scopo di un CAPTCHA è infatti quello di prevenire una registrazione di tipo massivo, ad esempio ad un servizio di webmail gratuita. In questo articolo parleremo dei diversi tipi di test che è possibile implementare, analizzeremo quanto sicuri sono queste varianti, e cercheremo di capire quali sono le contromisure usate per eludere i CAPTCHA e come impostarli correttamente per renderli accessibili a tutti.

Come sono usati i CAPTCHA

Il CAPTCHA è un test di tipo challengeresponse. Questo significa che all’utente viene presentato un testo, e successivamente gli viene richiesto di digitare lo stesso testo in una form. Considerato che questa azione richiede un ragionamento, si presume che sia eseguibile solo da un umano, non da un bot (i bot sono programmi scritti per ripetere automaticamente l’attività di una persona, ma non a questi livelli). Esistono diverse tipologie di CAPTCHA, vediamo quali sono.

CAPTCHA grafico

Questo è il test più comune. Si presenta all’utente un’immagine , in cui il testo appare più o meno distorto, e viene richiesto di inserire quel testo (che può contenere numeri e/o lettere) in una form. In figura 1 potete vedere un esempio.

Figura 1 –  Yahoo graphic CAPTCHA from Wikipedia

Figura 1 - CAPTCHA grafico utilizzato da Yahoo! (da Wikipedia).

Questa tipologia di test è relativamente semplice sia da implementare che da utilizzare. L’utente deve solo leggere il testo, replicarlo, e il test è concluso. Per il provider, in questo caso di un servizio di webmail, è inoltre molto semplice scrivere una procedura che, all’interno di una form standard, cambi l’immagine ogni volta che la pagina viene ricaricata. Questo è senza dubbio il modo più semplice per usare un CAPTCHA, ma è abbastanza? Più importante ancora, è accessibile? La risposta ad entrambe le domande è no. Vediamo perché.

CAPTCHA grafico e sonoro

La seconda tipologia di test integra un CAPTCHA audio a quello visivo. Questo è necessario poiché un test solo grafico necessita unicamente dell’utilizzo della vista per essere risolto, euna persona con problemi di vista non potrebbe registrarsi al servizio. Nel test grafico e sonoro viene aggiunta una funzionalità che legge il testo presentato (o legge un altro testo, dipende da come viene implementato), permettendo quindi anche ad una persona ipo o non vedente di inserire nella form il testo corretto. Di seguito un esempio.

Figura 2 – CAPTCHA grafico e sonoro di Gmail

Figura 2 – CAPTCHA grafico e sonoro utilizzato da Google per la registrazione a Gmail.

Il CAPTCHA in figura 2 risulta molto accessibile poiché anche l’attributo HTML alt dell’immagine è valorizzato come “Ascolta e inserisci i numeri che senti“, in questo modo è possibile cliccare sull’icona della sedia a rotelle, ascoltare un file audio (che in questo caso presenta dei numeri, non delle lettere come nell’immagine) e superare il test. Ancora più interessante in questo caso è che il CAPTCHA è localizzato. Nell’immagine potete vedere la versione italiana, e i numeri sono effettivamente letti da una voce italiana. La stessa localizzazione c’è anche per l’inglese e le altre lingue di Google. Un’altra cosa da notare è che questo test ha di fatto due modi per essere risolto: sia inserire le lettere viste che i numeri ascoltati permettono di passare il test.

CAPTCHA cognitivo

C’è un ulteriore modalità di utilizzare i CAPTCHA, ed è forse la più complessa ma allo stesso tempo la più affascinante, soprattutto se usata all’interno di un social network. Questo tipo di CAPTCHA chiede all’utente, invece che mostrare lettere e numeri, di effettuare un’operazione logica del tipo: quanto fa 3+3/2? Oppure di che colore è il cielo quando non piove? Un altro modo di impostare un CAPTCHA cognitivo è quello di utilizzare informazioni conosciute sia dall’utente sia da chi espone il servizio. Questo funziona molto bene proprio nei social network, ed è stato implementato da Facebook. Se Facebook infatti pensa che il login sia stato effettuato in maniera illecita, ad esempio proviene da un IP che l’utente non aveva mai usato, mostra all’utente alcune foto dei suoi amici, chiedendogli di identificare tra le varie foto una specifica persona. Questo tipo di CAPTCHA è tuttavia molto difficile da realizzare, visto che necessita di un notevole database di domande/risposte possibili, e questo è un problema di sicurezza di cui parleremo dopo. Nell’altro caso necessita di conoscere un buon numero di informazioni dell’utente, quindi è impossibile utilizzarlo su servizi non autenticati (come un WHOIS per un dominio, ad esempio), o ancora peggio nella fase di registrazione ad un servizio.

E per quanto riguarda l’accessibilità?

L’accessibilità, o meglio la non-accessibilità dei CAPTCHA è un problema reale, ed è stato analizzato molte volte nel corso degli anni. Nel 2005 anche il World Wide Web Consortium ha pubblicato un documento a riguardo. Il documento del W3C non è molto attuale in alcuni passaggi, ma le considerazioni finali sono sicuramente molto interessanti, i problemi che espone sono reali, e dovrebbe essere tenuto in considerazione da chiunque utilizza o intende implementare i CAPTCHA nei propri servizi web. Come detto prima i test esclusivamente grafici non sono accessibili da persone cieche o ipovedenti. Tuttavia anche utilizzando la grafica e l’audio resta il rischio di tagliare fuori un discreto numero di utenti. Questo può succedere se l’utente non ha la possibilità di ascoltare il test (per problemi hardware, per mancanza di plugin specifici, ecc.), oppure se il test è svolto in un ambiente particolarmente rumoroso. Prendendo come esempio il test di Google, l’audio è molto complesso da comprendere anche in una situazione normale e da parte di una persona senza problemi di udito. Questo succede quando si sposta l’asse troppo dalla parte della sicurezza, chi ci rimette è proprio l’accessibilità. Anche il CAPTCHA cognitivo ha molti problemi di accessibilità, a cominciare ovviamente da utenti non vedenti, che non riescono a comprendere le immagini proposte. Questo si inquadra in un contesto molto più complesso, visto che un social network in se non è propriamente il servizio più accessibile presente su Internet. In questo caso tuttavia è possibile usare altre informazioni già in possesso di chi propone il test, come ad esempio la data di nascita dell’utente, la sua squadra preferita, oppure una domanda e risposta fatta impostare all’utente in fase di registrazione. Questo può aiutare ad implementare un CAPTCHA cognitivo accessibile a molte persone.

Ma i CAPTCHA sono sicuri?

Ora parliamo di sicurezza. Come ogni strumento atto a prevenire un utilizzo illecito di un servizio, anche i CAPTCHA sono pesantemente attaccati. Considerando poi che spesso difendono la registrazione a servizi di webmail gratuite, quasi tutti gli attacchi vengono da spammer, che mirano a registrare quanti più account possibili, per poi usarli ed inviare email. Analizziamo ora alcuni metodi utilizzati per risolvere il test automaticamente, ma è importante tenere in considerazione che questo tipo di attacchi è in continua evoluzione, e i ricercatori presentano soluzioni sempre più evolute anno dopo anno.

Risolvere un CAPTCHA automaticamente

Come già detto i CAPTCHA sono stati creati per evitare che i bot inviino richieste in modo massivo. I programmatori di bot hanno costantemente lavorato su tecniche per permettere una lettura automatica dell’immagine, superando automaticamente il test. Queste tecniche sono state sviluppate in modo parallelo alla nascita dei CAPTCHA. Considerando che questo tipo di attacco è molto simile alle tecnologie OCR, il modo migliore per evitarlo è distorcere il testo nell’immagine, aggiungendo quindi maggiore complessità.
Un esempio di distorsione.

Figura 3 – CAPTCHA di Yahoo! distorto per evitare una lettura automatica.

Figura 3 – CAPTCHA di Yahoo! distorto per evitare una lettura automatica.

Nel CAPTCHA in figura 3, è stata aggiunta distorsione e complessità al test presentato da Yahoo!. Questo è però un caso in cui la sicurezza prevale sull’accessibilità. Poiché più il testo viene distorto meno diventa leggibile, questo avviene sia per strumenti automatici che per esseri umani, che abbiano problemi di vista o no. Quante volte avete ricaricato un CAPTCHA perché il testo presentato era illeggibile? Molte volte immagino
Anche il CAPTCHA audio può essere ovviamente risolto automaticamente. Molti programmi sono in grado di ascoltare delle parole e scriverle su un file. Analogamente a quanto detto per la parte grafica, anche per l’audio è possibile aggiungere disturbi sonori o aumentare il rumore di fondo. Questo a discapito dell’accessibilità, ovviamente, ma non è ancora abbastanza. Uno studio recente su questo argomento ha mostrato come, anche aggiungendo distorsione al file audio, il CAPTCHA è stato risolto automaticamente il 67% delle volte per Google, il 70% per Digg e il 45% per reCAPTCHA(che è probabilmente il servizio di CAPTCHA più usato sul web, di proprietà di Google stessa). E ovviamente più rumore o distorsione viene aggiunto all’audio, meno diventa comprensibile da chiunque.
Per quanto riguarda il CAPTCHA cognitivo, il suo punto debole è senza dubbio la base dati delle domande. Mentre una combinazione di parole e numeri è illimitata, in questo caso è necessario creare un elenco di domande e risposte da chiedere. Risulta quindi facile per un attaccante studiare il test, collezionare le possibili domande e preparare un bot che sia in grado di rispondere a tutte. Se il CAPTCHA cognitivo è basato invece su informazioni possedute sia dal gestore del servizio che dall’utente, risulta molto più difficile da attaccare. Ma questo come già detto richiede una registrazione preventiva, quindi non è utilizzabile su servizi anonimi o in una form di registrazione.

Attaccare l’algoritmo di generazione dei CAPTCHA

Come ogni generatori di numeri casuali, anche l’algoritmo che genera un CAPTCHA può essere attaccato e scoperto, in questo modo sarebbe possibile risolvere il test prima ancora che venga presentato all’utente. Questo tipo di attacco è tuttavia molto difficile da eseguire. I moderni algoritmi sono robusti, in molti casi analizzati da una comunità open source, ed è difficile che un attaccante spenda tempo e risorse per cercare di comprendere la logica dietro l’algoritmo. Può tuttavia succedere che un provider utilizzi un sistema di generazione di CAPTCHA molto vecchio, con un algoritmo prevedibile. Questo è uno dei motivi per cui molti utilizzano i servizi di reCAPTCHA, che risulta molto sicuro da questo punto di vista.

Risolvere un CAPTCHA manualmente

Questo tipo di attacco può sembrare una contraddizione: se devo risolvere un CAPTCHA automaticamente perché dovrei tentare di attaccarlo risolvendolo manualmente? La risposta alla domanda è semplice: se un CAPTCHA è creato per essere risolto da umani, usiamo gli umani per risolverli! Questo tipo di attacco può essere svolto in due modi. Si può includere il CAPTCHA da attaccare all’interno di un proprio servizio web, pubblicato dall’attaccante.

Un altro modo è di pagare delle persone per fargli risolvere quanti più CAPTCHA possibili. Questo caso è stato citato anche nello studio del W3C di cui avevamo parlato prima, notando come un operatore specializzato in questo può risolvere centinaia di CAPTCHA ogni ora.

Questo tipo di attacchi sono comunque molto costosi e spesso non valgono la spesa, considerato che un sistema di risoluzione automatico è comunque più veloce di qualsiasi umano, e che è complesso creare dei siti fake in cui includere un CAPTCHA da un altro servizio web.

Anche pubblicare un sito che presenti delle immagini pornografiche, in seguito alla risoluzione di un CAPTCHA è abbastanza inutile. Ci sono moltissime immagini immediatamente accessibili con una semplice ricerca, ed è improbabile che qualcuno perda tempo a risolvere un test per vederle. Questo tipo di attacco è poco più di una leggenda urbana, come analizza lo stesso Captcha.net in “L‘attacco tramite pornografia non è un problema“:

Mentre è molto semplice scrivere un bot che abusi di siti non protetti milioni di volte al giorno, reindirizzare i CAPTCHA per essere risolti da umani che vogliono vedere immagini pornografiche permetterebbe agli spammer di utilizzare illecitamente i servizi poche migliaia di volte al giorno. I conti di questo attacco semplicemente non tornano: ogni volta che un sito porno mostra un CAPTCHA prima di un’immagine rischia di perdere un utente, che si rivolgerebbe ad un altro sito senza quel blocco.

Devo monitorare i miei CAPTCHA?

La risposta a questa domanda è senza dubbio ! Chi espone un servizio deve mantenere un log di ogni cosa riguardi l’uso del CAPTCHA, e deve analizzare questo log molto attentamente.

Questo è necessario sia per la sicurezza che per l’accessibilità. È necessario analizzare quante volte gli utenti hanno fallito il test rispetto al totale degli accessi e, se avete un CAPTCHA audio e video, è necessario comprendere quanti utenti hanno passato il test leggendo le parole o ascoltando il file audio.

Analizzando questi log è possibile infatti capire se il test è realmente utile, se è troppo facile o difficile da passare, e quale soluzione è più efficace. Per esempio se pensate che il vostro servizio sia utilizzato da un piccolo numero di persone non vedenti, e i vostri log vi dicono che il CAPTCHA è stato superato al 50% per la parte visiva e al 50% per quella audio, questo può significare sia che la parte audio è vulnerabile ad attacchi, sia che la parte visiva è troppo complessa da leggere. Conoscere queste statistiche può senza dubbio aiutare a pubblicare un servizio migliore, e migliorare l’esperienza dei vostri utenti.

Correlando questi log con altre fonti, come ad esempio i log degli application server o dei firewall/IPS, è possibile avere informazioni chiare su chi, come e da dove sta usando (o forse abusando) dei vostri servizi.

Conclusioni

Abbiamo quindi fatto un tour sui tipi di CAPTCHA che possono essere usati, quali sono i punti di forza e le debolezze di ogni tipo, e come è possibile provare ad identificare abusi o possibili attacchi.

Come ogni misura tecnica i CAPTCHA non possono garantire il 100% di sicurezza sui vostri servizi. Sono uno strumento molto utile, ma è necessario implementarli molto bene. Bisogna pensare all’accessibilità, alla sicurezza e alla user experience, e questi sono problemi critici se il vostro servizio ha una platea di utenti molto ampia. Ancora di più se lo pubblicate come amministrazione pubblica o come servizio orientato ai cittadini.

La sicurezza del CAPTCHA può essere aumentata aggiungendo complessità, distorsione o domande logiche difficili (ma in gran numero). Bisogna però essere consci del fatto che più si aumenta la complessità, più il test diventa sicuro, ma meno è accessibile da una gran parte dell’utenza. Questo è il motivo principale per cui molti servizi che usano un CAPTCHA sono molto complessi da utilizzare, e questo genera frustrazione negli utenti, e quindi lamentele o abbandono del servizio. E di certo vorrete evitare questa situazione.

Come ulteriori scenari di implementazione, insieme ad un CAPTCHA in fase di registrazione ben bilanciato tra sicurezza e accessibilità e ben monitorato, è possibile attivare dei controlli ulteriori con questo test all’interno del servizio stesso. Se l’applicazione pensa ad esempio che l’utente stia facendo troppe operazioni in poco tempo, rispetto a quanto possa fare un essere umano, allora blocca la funzionalità e presenta un CAPTCHA.
Questo è esattamente quello che fa Google con il suo servizio di ricerca web, se provate a fare numerose ricerche con uno strumento automatico. Naturalmente Google non può mostrare un CAPTCHA ad ogni query di ricerca (non lo userebbe più nessuno), ma se il motore ritiene che voi siate un bot e non un umano, ferma tutto e vi chiede di risolvere un CAPTCHA cognitivo. E questo sicuramente rallenta e tenta di prevenire gli abusi.

In conclusione: rispettate sempre i vostri utenti, pensate bene a quale servizio state difendendo e bilanciate la sicurezza di conseguenza, e monitorate attentamente i log.

E sicuramente avrete un ottimo CAPTCHA!

Federico Filacchione
pubblicato originariamente come “CAPTCHAs, What They Are and How To Use Them” su Hakin9 numero 50© Software Press, Poland.