lunedì 21 dicembre 2009
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.
Un progetto la cui architettura sta emergendo in questi giorni, ha evidenziato una problematica ricorrente che riguarda la necessità o meno di strutturare i dati in modo relazionale nel database.
Per evitare di farla troppo lunga, partiamo da un esempio. Diciamo quindi di avere un modulo di una applicazione che deve eseguire del logging sulle attività svolte da un utente all'interno di un sito.
L'attività da loggare è ha un inizio, i dati da loggare cambiano a seconda di come opera l'utente nell'applicazione, termina quando l'utente ha completato un determinato task, il log deve essere cancellato dopo un certo tempo perché lo storico non sia eccessivo e per rispettare la privacy.
Il database è lo strumento ideale per mantenere questi dati? Se consideriamo il modo "classico" di gestione del database la mia risposta è no.
Facciamo un passo indietro e domandiamoci perché si sceglie il database. I motivi in cima alla lista sono: gestione "gratis" della concorrenza nell'accesso ai dati, ottime performance nella ricerca dei dati, capacità di relazionare set di dati eterogenei, etc.
Ma nel nostro esempio cosa ci serve di tutto ciò? Più che altro ci serve la gestione della concorrenza per cui sarebbe da pazzi eseguire la persistenza su un file xml.
Quale altra tecnologia ci permette di rispondere a quelle domande per lo specifico problema in esempio? Workflow Foundation non solo risponde a questi requisiti ma semplifica di parecchio lo sviluppo della soluzione:
- Alla crezione del nuovo log, viene creato una nuova istanza di workflow
- Dalla versione 4.0 possiamo gestire la logica del nostro esempio di logging (e i relativi dati) secondo una Flowchart, cosa particolarmente familiare a qualsiasi developer, quindi meno prona ad errori.
- I workflow possono essere "long-running" e sarà l'engine a gestirne la persistenza sul "media" che il developer ha stabilito. La persistenza può anche finire in un blob così come su un db relazionale. Il tutto è "nascosto" all'applicazione e come ogni disaccoppiamento questo è un grosso beneficio.
- L'avanzamento dell'attività dell'utente si ottiene dall'object model di Workflow, anche da una applicazione esterna di amministrazione. A partire dalla versione 4.0 ci sono anche gli strumenti già pronti come la dashboard di "Dublin".
- Il workflow può avere come ultimo stadio una "Sleep" di 2 mesi e poi decidere di cancellare la persistenza. Quei due mesi non sono altro che un blob posteggiato da qualche parte. In memoria non c'è nulla ma il runtime sa che, tascorso quel tempo, deve riattivare quell'istanza e farla proseguire. Il suo ultimo stadio è quello della cancellazione dello storico.
In sostanza basta disegnare graficamente il workflow, oops flowchart, (magari dopo aver sviluppato delle adeguate custom activity) e dirgli che ci serve il servizio di persistenza, e il gioco è fatto.
Magari abbiamo configurato la persistenza di WF su un db relazionale, o magari abbiamo usato Table o Blob di Windows Azure, ma quel che più importa è che non abbiamo disegnato un db, non abbiamo scritto query o sp, non abbiamo un datalayer per questa specifica parte dell'applicazione.
Ovviamente il concetto è trasportabile anche a molti altri esempi ma non è generalizzabile anche se ritengo che l'abitudine ad usare il db per tutta la persistenza nasconda soluzioni più brillanti.