Una settimana fa una neonata società di servizi di posta elettronica, StrongWebmail, del gruppo TeleSign, ha messo in palio la cifra di $10.000 per chi fosse riuscito a penetrare nella casella mail del loro CEO (amministratore delegato).
Tanta confidenza deriva dal metodo utilizzato per autenticarsi alla casella di posta. Dopo aver inserito i canonici username e password, è infatti necessario un ulteriore PIN di cinque cifre ottenibile tramite il proprio cellulare con un SMS o una telefonata.
Ad un malintenzionato non basterà più quindi indovinare o rubare le credenziali d’accesso, perché ogni volta ci sarà un valore non predicibile, ed egli difficilmente avrà anche accesso al cellulare della vittima.
Per dimostrare la loro fiducia in questo meccanismo forniscono ai partecipanti alla competizione anche username e password del CEO, pari rispettivamente a ceo@strongwebmail.com e mustang85.
Una sfida simile non poteva non essere raccolta da una folta schiera di smanettoni, così, come era lecito aspettarsi, ecco dopo due giorni materializzarsi il risultato: un gruppo di hacker composto da Aviv Raff, Lance James e Mike Bailey è riuscito ad avere accesso alla webmail del CEO.
Dopo un’iniziale dubbio sul fatto che fossero state seguite le regole del contest (come se un malintenzionato dovesse seguire delle regole…), il montepremi è stato loro ufficialmente assegnato.
Come hanno fatto? Hanno realizzato un attacco a forza bruta grazie alla potenza di un super computer? Hanno violato l’indistruttibile logica di autenticazione della casella di posta? No. Hanno usato un attacco cross-site scripting (XSS).
Dettagli dell’attacco non sono ancora disponibili (se non un paio di screenshot), ma dovrebbero esserlo, almeno in parte, a breve.
Come mi è capitato già altre volte di ricordare, un attacco XSS prende di mira l’utente di un servizio web facendo sì che il suo browser esegua del codice (di solito JavaScript), iniettato nell’applicazione vulnerabile, in grado, per esempio, di catturare la sessione dell’utente (i cookies) e di mandarla all’attaccante che può usarla per autenticarsi al servizio come se fosse la vittima, senza bisogno delle sue credenziali.
I tre hacker, ricercatori noti nella scena della sicurezza web, hanno così mandato una mail al CEO Darren Berkovitz con un link malevolo e hanno atteso che lui ci cliccasse sopra (un po’ di social engineering serve spesso negli attacchi XSS, soprattutto se reflective e non stored).
E’ probabile che i gestori di StrongWebMail non si aspettassero un attacco simile. A dimostrazione del fatto che spesso non si ha una visione olistica (d’insieme) della sicurezza informatica.
Hanno probabilmente concentrato tutte le loro attenzioni sul design di un robusto (e meritorio) sistema di autenticazione. Ma non basta, esistono tutta una serie di fattori collaterali che possono contribuire a rendere insicuro un sistema informatico o un servizio web.
Un attacco XSS è un caso (spesso il più semplice), ma anche un attacco di SQL injection sarebbe potuto essere utile per accedere al database contentente le caselle di posta e non solo. E tutta un’altra serie di vulnerabilità tipiche delle applicazioni web: dal directory traversal all’OS command execution. Oppure una vulnerabilità nel web server.
Dal canto mio, dopo un rapido test dell’applicazione web che fa girare il sito principale, sono stato in grado di far generare un errore (ora corretto) che, googlando, pare essere espressamente legato al CMS Joomla, che, manco a dirlo, in passato è stato affetto da numerose vulnerabilità.
Il design di un’applicazione (in particolare dei meccanismi di autenticazione a ACL) è un elemento cardine e importantissimo, ma gli errori di programmazione o la programmazione insicura è sempre dietro l’angolo.
Per quanto riguarda invece un errore di design, che cosa sarebbe potuto andare storto?
Per esempio la generazione del PIN potrebbe non essere (pseudo)casuale, ma magari consecutiva crescente. Se per esempio io fossi registrato a StrongWebmail e mi loggassi appena prima o appena dopo una persona di cui già conosco username e password, potrei con semplicità ricavare il suo PIN partendo dal mio.
Altro problema, effettivamente esistente e non supposto, è la trasmissione (in)sicura delle credenziali sulla rete. La pagina di login è infatti su HTTP in plain text, senza l’uso di SSL. Ciò significa che sarà veramente facile mettere in atto un attacco man-in-the-middle (di cui abbiamo già parlato in due appuntamenti) per catturare le credenziali o dirottare la sessione.
Anche l’uso di HTTPS spesso non garantisce una protezione certa contro gli attacchi MITM, come ho già avuto modo di sottolineare in passato.
Un altro elemento che è importante sia casuale è il token di sessione presente nei cookies: si rivelasse predicibile o bruteforsabile, un malintenzionato potrebbe autenticarsi con la nostra sessione senza bisogno delle nostre credenziali.
Un’ulteriore fattore negativo è la presenza della funzionalità “do not call” che andrebbe attivata solo (nell’idea degli sviluppatori) quando si è gli unici ad usare un certo computer per accedere alla webmail e si ritiene sicuro quel sistema.
Già, perché se il tuo computer è infetto e hai quella funzione attiva, qualcuno potrebbe accedere con semplicità alla tua casella di posta, e addio autenticazione-super-sicura-con-PIN-sul-cellulare.
Ma uno come fa a sapere se il proprio sistema è sicuro? Se si vuole avere veramente la sicurezza del cliente, è meglio non tentarlo con scelte che non è in grado di prendere coscientemente e con un sistema di login più rapido e “semplice”.
Morale della favola: se ci si vuole fare pubblicità, non è una buona idea dire “bucateci se ce la fate”, perché si finisce solo col fare brutte figure.
Ma StrongWebmail non demorde e annuncia già che ci sarà un nuovo contest: “Non molleremo finché non avremo dimostrato che un’autenticazione basata sul telefono è il più sicuro tipo di protezione username/password disponibile”.
Evidentemente non hanno ancora capito la lezione.
P.S. Come tutti saprete ieri sera è stato presentato il nuovo iPhone e relativo OS 3.0. Come era facile prevedere, hanno già incominciato a girare dei malware che si spacciano per software per fare il jailbreak del melafonino. Be aware!
UPDATE: In un’intervista, Lance James dà maggiori dettagli sulla realizzazione dell’attacco. Veniamo a sapere che il vettore di attacco dell’XSS è stato inserito nel soggetto di una mail inviata al CEO. Nel momento in cui egli visualizza la mail malevola attraverso la webmail, l’attacco parte automaticamente e gli ruba i dati della sessione. In questo modo l’attacco è ben più nascosto e sofisticato del solito clicca-questo-link.
io invece lo trovo un ottimo modo (ed economico) per fare il testing di un sistema di sicurezza… hai decine (centinaia?) di hacker che tentano in tutti i modi di infrangere le tue barriere… chi ci riese guadagna 10.000 dollari, mentre l’azienda ottiene pubblicità, visibilità, bug fixing a un prezzo ridicolo e in tempi rapidissimi.
Ditemi voi se è poco ;-)
Io avrei tentato un altro sistema: furto del cellulare…
Vabbeh..
Sono gli stessi stratagemmi che si usano per i conti on line..
Da ricordare però che più aumenti le protezioni più l’uso di tutti i giorni diventa scomodo!
Ricordo a tutti che nel 90% dei casi la falla di sicurezza è costituita DALL’UTENTE!!!
fregati con l’ingegneria sociale?
beh è ora che cambino nome da Strongwebmail a qualcosa di più appropriato
davvero interessante come articolo, complimenti! Quindi co’un esca hanno avuto l’accesso alla webmail.. grandi!
Ma il CEO è andato a cliccare proprio quel link malevolo, non poteva stare più attento?
Ad ogni modo, usare il cellulare non mi sembra una gran trovata. Basterebbe usare quell’aggeggio che ti forniscono certe banche che serve a generare un codice univoco ogni 30 secondi.
Questa cosa è da manuale, non è la prima volta che un servizio mail si presenta come super sicuro ed immediatamente viene bucato, era successo anche ad Oracle con la presentazione del suo Collaboration Suite che veniva presentato come “unbreakable”, che poi, tanto unbreakable non si dimostró’.
beh, avrebbero potuto metter su un sistema a chiave asimmetrica perlomeno per lo scambio dati di autenticazione/sessione…..almeno sarebbero state un po’ più difficili le cose per gli hacker…..correggetemi se sbaglio….
Suppongo che il solito NoScript avrebbe salvato la situazione, giusto?
E un sistema a smartcard per l’autenticazione come sarebbe? A patto di non perderla…
Epic fail, come dicono i giovani oggi.
[…] (fonte AD) […]
Personalmente ritengo invece che la società ha avuto un ottima intuizione. Contest = pubblicità. Inoltre 10 K$ non è una cifra da capogiro per una società che si occupa di sicurezza informatica, di medio-alto livello. In questo modo hanno potuto sperimentare sui propri sistemi in che modo poteva essere portato un attacco, e di conseguenza aggiustare le falle.
Così facendo al prossimo contest si parlerà ancora di loro, avranno migliorato il sistema e con molta probabilità saranno più competitivi sul mercato.
Senz’altro otterrano più fiducia dai clienti con questo nuovo metodo, e perchè no, magari proporlo anche ai big della rete (gg, ms…).
Saluti
Quindi rimane ancora il principale problema: quello che sta tra la sedia e la tastiera :)
Ho inserito un update al fondo dell’articolo. Il CEO (o chi per lui) è stato meno stupido di quanto supposto inizialmente.
Non sottovalutate la complessità di certi attacchi, certe volte non è così semplice evitarli.
Per lakar:
Sì, probabilmente NoScript avrebbe bloccato l’attacco, a meno che non si trattasse di un vettore in grado di evadere i suoi filtri.
Per Umberto e Nicola:
Non stiamo parlando di problemi di un sistema di autenticazione. Una smartcard o la crittografia asimmetrica non avrebbe assolutamente aiutato contro questo tipo di attacco.
Per Paganetor e Alessio:
Non so voi, ma per me una società che fa questa figura perde solo di credibilità.
C’è una ragione ben precisa se questi hacking contest non sono diffusi e non possono sostituire un’attività di penetration testing o vulnerability assessment fatta da professionisti. I partecimanti alla competizione non devono seguire nessuna regola etica e non sono obbligati a segnalare tutte le falle che trovano. Vince chi sfrutta per primo una falla, ma tutte le altre che restano? Fai 10 contest di fila? Bella roba…
Per non parlare della pubblicità, che io continuo a ritenere negativa.