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.
