Le webmail sono morte, viva le webmail

Il fenomeno Webmail 2.0 è scoppiato da quando Google con la sua Gmail, ha scosso i concorrenti proponendo svariati giga per archiviare la propria posta elettronica online.
Non sempre però va tutto come dovrebbe e succede che la privacy della propria casella viene messa a rischio da vulnerabilità XSS e CSRF; evidentemente di criticità media-bassa nella svariata maggioranza di casi.
In questo caso però, grazie alla somma di più problemi un attacker può modificare le configurazioni delle caselle di posta elettronica delle vittime, impostando l’inoltro automatico di tutte le mail in arrivo verso un account e-mail da egli controllato. In tal modo è possibile violare la riservatezza delle caselle delle vittime senza ricorrere ai comuni metodi di identity stealing (cookie stealing, credential stealing), ma semplicemente inviando e-mail, preparare ad arte, alle vittime.

La pericolosità di questa tecnica è resa critica grazie a tre fattori:
  • semplicità di exploiting (cross-browser)
  • scarsa awareness della vittima (nessuna interazione richiesta oltre all’apertura della mail stessa)
  • diffusione sul web (ampia diffusione della piattaforma vulnerabile e possibilità di propagazione virale)
Sia chiaro, nessuna novità nella categoria delle vulnerabilità delle Web Application, ma una dimostrazione di come l’insieme di alcune di queste può portare ad uno dei più gravi problemi mai registrati on-the-wild su Web Application. I bug scoperti sono adatti per sfruttati da quello che potrebbe essere uno dei più grandi e gravi Worm delle Web Application: numero di domini Internet coinvolti maggiore di 10 (cross-domain) e semplicità di propagazione.

Prima di scendere nei dettagli del funzionamento dell’attacco è doveroso precisare che il problema è stato corretto a tempo di record dal vendor che si è dimostrato attento alla sicurezza dei propri clienti.
Le WebMail interessate dalle vulnerabilità sono quelle basate sul framework di messaggistica “Memova” sviluppato da Critical Path. Si tratta di una soluzione per la gestione della posta elettronica enormemente diffusa sul Web.

Giusto per riportarne qualcuno:
  • Tiscali IT/UK/NL
  • Wind
  • Telecom
  • Vodafone
  • Swisscom
  • Telefonica
  • Virgin
  • Sonera
  • Terra.es
  • Telia
  • T-Mobile
  • FastwebNet
  • Ono
  • Regione Puglia
  • Regione Sicilia
  • Diversi domini gov.uk
Si tratta di ISP diffusi in Europa con una enorme base di utenti.
Ovviamente su ciascuna installazione, la soluzione Memova è stata opportunamente personalizzata, sia nel look che nelle funzionalità per venire incontro alle necessità del cliente, ma le caratteristiche di base sono comuni e, purtroppo, comuni sono anche le vulnerabilità.
Il grafico che segue riassume la vita dell’attacco che può essere portato a termine grazie alle vulnerabilità scoperte:

L’attaccante invia una e-mail preparata ad arte alla casella e-mail della vittima
La vittima legge l’e-mail e in maniera trasparente viene impostato l’inoltro automatico di tutte le e-mail in ingresso
Conoscenti, colleghi ed amici della vittima scrivono e-mail alla vittima stessa
Tutte le e-mail in ingresso nella casella della vittima vengono inoltrate all’attaccante in maniera trasparente.
L’impostazione dell’inoltro automatico è solitamente disponibile all’utente sotto le voci “Impostazioni” o “Opzioni” della WebMail. Questa opzioni non viene tuttavia consultata e modificata di frequente, per cui un’eventuale modifica di queste configurazioni passerebbe verosimilmente inosservata per parecchio tempo.

In alcune Webmail, interessate dalle vulnerabilità, non viene concessa all’utente finale la possibilità di impostare l’inoltro automatico tramite il menù delle opzioni; in tale scenario è praticamente impossibile per la vittima disabilitare le opzioni di inoltro, impostata grazie alle vulnerabilità scoperte, senza il supporto dell’assistenza tecnica dell’ISP.

Per il Proof of Concept delle vulnerabilità sono state analizzate le tre più popolari WebMail italiane (almeno in termini di account registrati) che tra l’altro fanno uso tutte e tre del framework Memova:
  • Tiscali
  • Libero (Wind)
  • Virgilio (Telecom)
Tramite l’invio di una mail contenente un unico vettore di attacco è possibile infettare gli account di tutte e tre le WebMail, impostando le opzioni di inoltro automatico verso un account di posta elettronica controllato dalla vittima. Nonostante il PoC sia stato testato solo sulle 3 WebMail sopra descritte, è verosimile attendersi che anche nelle installazioni presso altri clienti, il software di filtering di Memova sia vulnerabile a questo XSS.
Per l’invio della mail l’attacker ha la necessità di creare un testo ad-hoc in modo da sfruttare le vulnerabilità presente sui filtri di validazione dell’input presenti nelle WebMail coinvolte. Il vettore riportato sopra è studiato ad hoc per evadere i filtri anti XSS di tutte le WebMail testate, sia nella loro vecchia versione, sia nella loro nuova versione 2.0 (basata su tecnologia Ajax). All’apertura della mail, il vettore inviato viene posizionato nel codice HTML di un iframe preposto alla visualizzazione del testo di ciascuna e-mail.
Il codice del vettore richiama un file JavaScript ospitato su un server Web in possesso all’attaccante che viene eseguito nel contesto dell’iframe (es: mioisp.it )
In alcune delle implementazioni testate esiste un meccanismo di “protezione2 per limitare i danni provocati da XSS abbinati a CSRF: il dominio dell’iframe in cui viene letta la mail (e quindi eseguito il JavaScript) è differente dal dominio della WebMail (es. mail.mioisp.it).
Esiste tuttavia un meccanismo per aggirare queste limitazioni:
  1. occorre individuare un secondo XSS sullo stesso dominio della WebMail (es. mail.mioisp.it) e senza la presenza del token di sessione (che non abbiamo ancora a disposizione)
  2. tale XSS (di tipo reflected) viene richiamato come source di un iframe creato all’interno del frame di lettura della mail
  3. il Reflected XSS può avere accesso alla document.location della WebMail (steso dominio), riuscendo così a recuperare il token di sessione
  4. Il reflected XSS può a sua volta lanciare attacchi CSRF verso pagine del dominio “mail.mioisp.it” riuscendo così a modificare i settagli dell’inoltro automatico
Svincolato dalle restrizioni della Same Origin Policy, ed in possesso del token di sessione il codice del reflected XSS può effettuare chiamate XmlHttp verso qualunque risorsa presente sul dominio “mail.mioisp.it”.
In particolare la URL da chiamare per impostare il forward automatico delle mail in arrivo è:

POST /cp/ps/Mail/preferences/SetForward

Questa pagina è sempre disponibile sulle installazioni testate di Memova, anche in quelle in cui l’opzione di inoltro automatico non è disponibile per gli utenti finali della WebMail.
Come già ipotizzato qualche riga sopra, in una ottica teorica, ma praticamente realizzabile e funzionante, potrebbe essere creato un “worm” che sfruttando le vulnerabilità riportate sia in grado di auto replicarsi leggendo la rubrica o i mittenti e-mail presenti nella “inbox” della vittima. In questo modo si creerebbe un effetto a catena che comprometterebbe milioni di caselle e-mail interessate dalle vulnerabilità.
Avendo, inoltre,il controllo completo della casella e-mail della vittima sarebbe possibile effettuare il furto d’identità scrivendo e-mail a nome della vittima senza fare lo spoofing degli header.
Sulla base di una scelta “etica” e per rispetto nei confronti di tutte le parti coinvolte (la privacy degli utenti da una parte, il rispetto del lavoro di professionisti dall’altra) il codice sorgente e le specifiche tecniche alla base del PoC non verranno divulgate.

E’ disponibile un video dimostrativo (le notizie che si vedono a 2 minuti e 24 secondi evidenziano la data di registrazione) di quanto fin ora descritto e una advisory dettagliata del problema.

16 Aprile 2009

Rosario Valotta
Matteo Carli
Č
ĉ
Rosario Valotta,
May 29, 2009, 2:00 PM
Ċ
Rosario Valotta,
May 29, 2009, 1:57 PM
Comments