martedì 22 dicembre 2009
Nel post precedente ho bloggato su Verisign e a quanto sembra i rumors del mio blog, passando da Twitter, sono arrivati a destinazione. Grazie alla globalizzazione spero che presto avremo da Verisign solo pagine https. Aspetto fiducioso.
Il problema però non è un caso isolato. Nei commenti del post precedente, Fabrizio mi ha segnalato che sul sito di Ubuntu la faccenda è pure peggio! In quella pagina infatti viene indicato di scaricare le root come file di testo dal link: http://lxr.mozilla.org/seamonkey/source/security/nss/lib/ckfw/builtins/certdata.txt appartenente al dominio mozilla.org.
In pratica viene detto che quella pagina http e quindi non protetta viene usata in modo automatico per installare 93 certificati root. Con un attacco Man In The Middle estremamente semplice (trattandosi di file di testo basta un filtro di ettercap di poche righe) si può installare una root dentro la macchina Linux che sarà perciò vulnerabile agli attacchi già citati nel mio post precedente. Mentre l’attacco a Verisign richiede un minimo di collaborazione dell’utente, qui l’attacco ha una percentuale di riuscita decisamente superiore.
Ma non è finita. La vetrina degli orrori vede queste Certificate Authories che forniscono le root sempre in http, quindi attaccabili in modo estremamente semplice:
Non è ancora finita. Nelle stesse condizioni di Verisign, cioè pagina http con post in https e quindi vulnerabili, ci sono:
Il problema è più che serio. La sicurezza di un sistema dipende da tutti gli attori del sistema. Anche se gli algoritmi alla base di SSL sono sicuri, questo genere di problemi possono causare il fallimento totale. Voglio ricordare che tra gli attori del sistema c’è anche l’utente finale che deve controllare di essere su una pagina sicura con un certificato valido.
Verisign ha sul proprio sito il Graal degli Hacker: il download dei certificati root delle più importanti Certificate Authority.
Quale Black-Hat non vorrebbe installare il proprio certificato root sulle macchine degli utenti da attaccare? Avere sulla macchina della vittima un certificato root significa poter generare certificati validi emessi per ebay, paypal, banca di qui, banca di là, etc. etc. Poi hostare un clone di quel sito sul proprio pc, corredato del certificato "autentico" e infine dirottare con un "dns poisoning" l'utente sul proprio pc.
Cosa può accadere se l'hacker possiede una root Certificate Authority che è installata sul nostro PC?
Può accadere che utente navighi sulla propria banca, ma grazie ad un dns poisoning viene dirottato sul sito dell'hacker. Quello che vede è un perfetto clone del sito della banca con tanto di certificato valido e una connessione https assolutamente impeccabile. Non è un attacco "delizioso"?
Torniamo all'inizio. Il punto di partenza è che l'utente deve in qualche modo essere convinto a scaricarsi le root aggiornate di Verisign e l'hacker deve intercettare il download. Come e quando importa poco, si va da un banale attacco di social-engineering ad una reale esigenza di aggiornare i certificati.
Dove sbaglia Verisign? La pagina di download delle root è in http .... fantastico tenendo conto che a Verisign i certificati non costano neppure 1 cent 
.
L'utente accorto vedrà subito che il post è verso un sito https ma qui casca l'asino:
- L'hacker esegue l'attacco sulla pagina http e sostituisce il post da https ad http, quindi questo link non sarà mai in https
- Se si usa SSLStrip, quell'https per "magia" torna ad essere http, come ho fatto vedere ai recenti TechDays/WPC.
L'attacco Man in The Middle consiste nell'usare un tool come Ettercap (ma ce ne sono molti altri) per intercettare l'attività tra i client e i server. Per cui anche se non si è fisicamente in mezzo, è possibile intercettare il traffico di rete tra due pc. È comunque necessario essere su una tratta di rete che permetta di porre l'attacco. Non so se la grande lan di Fastweb sia soggetta all'arp poisoning che ho mostrato nella mia sessione, ma certamente sono più le reti che possono accusare il colpo di quelle protette da questo tipo di attacchi.
Una volta intercettato il download l'utente riceve uno zip in cui uno o più certificati sono stati creati dalla Certificate Authority dell'hacker.
Lo zip contiene ben 41 certificati Root!
Installare una root sul pc della vittima significa che quel pc validerà in modo positivo qualsiasi certificato emesso da quella root. I risultati sono devastanti.
Una raccomandazione finale. Come dico sempre, fate le prove attaccando delle macchine ma solo in reti di test o in azienda solo dopo aver avvisato amministratori e utenti. Non ci sono deroghe a queste regole.
Neve e ghiaccio sono la condizione meteo di parecchie città di questa mattina. Il buon cittadino si tiene informato seguendo i siti web dove può vedere con i propri occhi la situazione reale.
Così apro il sito www.autostrade.it per capire cosa sta succedendo. Il sito non è raggiungibile per (presunti) troppi hit dei buoni cittadini che vogliono informarsi.
Uhm, qui c'è qualcosa che non torna. Una azienda, le autostrade spa, offre un servizio ai suoi clienti, il sito web e le webcam. L'utilità del sito è proprio nei momenti difficili: situazioni limite del meteo, picchi di traffico, lavori in corso, etc. Se il sito fallisce nel dare le informazioni in questi casi limite, è inutile.
Il paragone è il sito di un eCommerce nel periodo di Natale. Se per i troppi collegamenti il sito non funziona, perdo i clienti.
Fino a qui posso già immaginare i commenti a questo post in cui viene sottolineato che autostrade non danno importanza al cliente in quanto monopolisti e con un'eredità di mentalità "pubblica".
Sono però convinto che l'apparente (?) boriosa mentalità monopolista non basti a giustificare le cattive scelte. Un sito (servizio) che funziona giova anche al monopolista, perlomeno per lucidare un po' l'immagine aziendale.
Guardiamola quindi dal punto di vista di chi ha realizzato il sito:
- l'architettura del sistema è pensata per essere scalabile? No
- è stato previsto il fallback ad una pagina alternativa, come dice Alessandro, con le sole informazioni essenziali? No
- la pagina client è sufficientemente leggera da reggere carichi improvvisi? No
- ...
Il fallimento è quindi il matrimonio tra committente, team di sviluppo e servizio di hosting.
E ancora peggio è l'utente del sito che considera normale, causa maltempo, che ci sia un disservizio su un sito che serve proprio in caso di maltempo.