Quanto è facile rubare password?

Ormai anche i muri sanno che le connessioni https sono da preferire a quelle http, le connessioni imaps a quelle imap (143/TCP) o le connessioni submission SSL/TLS sono da preferire a quelle smtp (25/TCP) qualora ci si autentifichi per inviare email. 

Questo è assodato, ma la domanda che spesso mi rivolgono è "ok, ma chi vuoi abbia mai le competenze per catturare le mie password?". Proviamo a fare un laboratorio per cercare di capire quanto è semplice.

Come in linea con il resto del blog, in questo articolo non verrà spiegato come fare, lo scopo esclusivo è quello di sensibilizzare alla sicurezza informatica.

L'articolo è rivolto sia ai normali utilizzatori, sia a chi ha a che fare con queste tecnologie e spesso per "pigrizia" o per mancanza di volontà preferisce configurare connessioni in chiaro piuttosto che seguire la strada corretta di dotare ed utilizzare sul proprio server un certificato valido.

Hardware

Per questa prima prova, inizieremo a fare un Man in The Middle (MiTM) su una connessione ethernet, interrompendo in maniera silente ed invisibile un collegamento fisico.

Nello specifico, banalmente ci siamo dotati di una qualsiasi macchina con 2 schede di rete, intercettando una patch.

Più "in alto" intercettiamo la patch, e più informazioni carpiamo. Se intercettiamo la patch del router, è evidente che avremo informazioni riguardanti l'intera rete, se intercettiamo solo quella di un host, la nostra ricerca si limiterà a quest'ultimo ed al traffico di broadcast.

Lo stesso ragionamento vale in ambito geografico, ricordandoci che internet è un insieme di nodi e rimbalzi da un punto "A" ad un punto "B" e nel mezzo attraversiamo potenzialmente decine di scenari in cui questa operazione di sniffing è facilmente fattibile.

Software

Come sistema operativo abbiamo utilizzato una distribuzione Linux specifica e normalmente utilizzata per questo tipo di attività, tuttavia avremmo potuto fare la medesima cosa con una distribuzione qualsiasi e persino con una macchina Windows con uno sniffer di rete attivo. L'aver utilizzato una distribuzione specifica ci ha solo velocizzato le operazioni di installazione dei tool, facilmente reperibili in rete.

Questa è sostanzialmente la cronologia delle operazioni, con relativo tempo impiegato.

1. Scaricamento ed installazione della distribuzione Linux (40m)
2. Configurazione del bridge tra eth2 ed eth4, le nostre NIC (10m)
3. Esecuzione e configurazione dei tool di sniffing e logging delle password (5m) 

I risultati

Nel giro di meno di 1h abbiamo creato una macchina in grado di catturare tutto il traffico e restituirci le credenziali di accesso in chiaro.

Qui sopra possiamo osservare il risultato di un test di login su un form di autenticazione in HTTP e di un'interrogazione IMAP su di un qualsiasi server di posta. Facile, no?

Access Point liberi

Facciamo un passo in avanti. Per catturare quelle informazioni abbiamo bisogno indubbiamente di un accesso fisico. Potrebbe essere più semplice, quindi, lasciare un simpatico Access Point aperto a tutti.

Ed ecco che:

1. Installeremo e configureremo il sistema di emulazione AP (15m)
2. Creeremo le regole di NAT dalla (nel nostro caso) wlan2 alla br0 (5m)
3. Installeremo e configureremo un Server DHCP per rilasciare gli indirizzi alla wlan (15m)

E come una carta moschicida, in un attimo avremo il traffico (e quindi le relative password) di chi vi si connette, dando in cambio un po' di banda.

Spiegato, concretamente, uno degli evergreen della sicurezza "user-side": mai connettersi a reti non affidabili o aperte. Il rischio di incappare in reti volontariamente lasciate aperte per raccogliere dati è altissimo.

Proxy SSL

Spostiamoci ancora più in là. Creiamo un proxy al cui interno fare decrypt del traffico crittografato. Il funzionamento è pressappoco questo (agiremo creando delle semplici regole di NAT in grado di intercettare le porte su cui il traffico non in chiaro tradizionalmente avviene):

L'utente, come spesso accade, avrà una richiesta di accettazione di un certificato (a sinistra una connessione sicura, a destra una alterata). E' evidente che qualsiasi proxy deve necessariamente riscrivere il traffico, quindi il massimo che si può fare è generare un certificato per la porzione di traffico Proxy-Client.

All'interno del proxy SSL, quindi, vi è una generazione di un certificato forgiato ad hoc per la sessione, ed ogni sessione ha il suo certificato creato in real time con lo scopo di ingannare l'utente.

Sostanzialmente tutto il traffico originariamente crittografato, diviene in chiaro, esponendoci ai rischi di cui sopra.

Ed eccoci al secondo evergreen informatico: "non accettare mai tutti i certificati, ovvero non cliccare sempre e solamente su continua".

NB: Se si importa la root CA del proxy, e quindi l'attaccante ha accesso alla macchina client, i certificati vengono visti come verdi!

More, more and more...

Non ci siamo spinti oltre, non abbiamo parlato di arp poisoning con lo scopo di dirottare il traffico verso di noi al posto del gateway (magari lo faremo in un prossimo articolo), non abbiamo parlato di DoS su WiFi con lo scopo di sostituirsi ad un Access Point, non abbiamo parlato di fake web page con lo scopo di fare injection di codice malevolo... insomma... c'è tanta carne sul fuoco già in questo articolo.

Le morali della favola sono:

• Evitare come fosse peste bubbonica le connessioni in chiaro (se un sito è HTTP, inserire credenziali non è mai una buona idea)
• Quando un certificato https è "rosso", c'è un motivo. E se il browser vi segnala un problema, tenetene conto.

Cosa succede quando si risparmia troppo sullo storage in un ambiente virtuale?

In ambiente virtuale, il datastore è sicuramente uno degli aspetti più importanti e più sottovalutati in assoluto. Non è inusuale vedere errori grossolani di dimensionamento ed osservare un sovrautilizzo dei dischi SATA (lenti per definizione) e di RAID hardware con performance poco più di "fake raid".

Questo è vero sia quando il datastore è locale e direttamente collegato al singolo server, sia (e peggio) quando il datastore è condiviso da un pool di server.

Tipologie di SAN

Qui abbiamo approfondito come creare una SAN iSCSI con dischi in RAID su una LUN LVM Linux affinchè sia collegata con un pool di server VMWare. Questo procedimento non è differente da cosa accade nei NAS economici, anch'essi con una loro distribuzione linux che si occupa di gestire i dischi ed i collegamenti. Questa architettura, tuttavia, ha dei profondi limiti.

Possiamo dire, riassumendo banalmente, che gli storage si dividono (non me ne volete, è una mia personale classificazione) in:

• Software Storage (molto economici), ovvero tutti i marchi che utilizzano a bordo un OS Linux e la suite md a gestione dei raid (o anche un Windows Storage Edition, se preferite)

• Hardware Storage (molto costosi), ovvero tutti i marchi che implementano principalmente a livello hardware la gestione dei dischi

Nel primo caso vedremo ovviamente delle latenze e, per quanto performante potrà essere il sistema, non potrà mai avere un paragone che non sia schiacciante verso la più performante soluzione hardware. Ma si può fare qualcosa? Abbiamo margini di movimento? Lo vedremo nel proseguo dell'articolo.

I costi

In verità non ci sono grandi vie di mezzo sull'aspetto economico. C'è una linea di demarcazione che suddivide nettamente il prodotto "Software" più costoso dal prodotto "Hardware" più economico. Questo mette in difficoltà chi, come me, sviluppa anche progetti e preventivi. Da un punto di vista è facile risultare costoso e perdere di competitività, da un altro è facile quotare un prodotto economico ma non in grado di essere all'altezza delle aspettative (e questo in ambienti virtuali è un disastro).

Allora ho deciso di dedicarmi all'ottimizzazione di un prodotto economico, impiegando (purtroppo) mesi nell'osservazione e nell'affinamento di tutto il possibile per spingere al massimo lo storage software, basato su linux, che avevo tra le mani.

Ottimizzazione di un prodotto commerciale basato su Linux

Il prodotto su cui ho lavorato, un top di gamma di un noto produttore dal nome breve, aveva 8 dischi da 4Tb SATA WD RE, per un totale nominale di 32Tb. Processore Xeon, 32Gb di RAM ECC e 8 NIC, di cui 4 a 10Gbit. In aggiunta, due dischi M2 SSD da 128GB in RAID1 a fare da cache sia in lettura sia in scrittura.

A leggere i datasheet ed i performance test, era una Ferrari. Poteva essere usato anche al CERN di Ginevra. La verità è stata decisamente più mesta ed impietosa.

I primi due mesi, abbiamo avuto latenze così gravi e performance così basse da avere macchine corrotte, datastore persi dagli host, storage vmotion falliti. La media delle latenze si aggirava intorno ai 600ms (e per chi non lo sapesse, oltre i 40ms uno storage è già palesemente e gravemente in crisi).

Non ci siamo persi d'animo, per i successivi 6 mesi è stato un continuo di ticket aperti con il supporto oltre continente, ma senza alcun esito. 6 mesi del tutto inconcludenti. Senza contare gli innumerevoli bug scovati che ci hanno indotto a pensare a processi qualitativi di revisione del software decisamente carenti.

Questo ne è un esempio: cache SSD abilitata, a detta del produttore una features in grado di velocizzare esponenzialmente lo storage. Peccato che, a dischi SSD pieni, le operazioni di riciclo della cache diventavano una cozzaglia di colli di bottiglia così gravi da mandare durante qualche storage vmotion persino in timeout il datastore su vmware (14 secondi, QUATTORDICI SECONDI DI LATENZA, avete letto bene) con una frequenza di una volta ogni 4-5 giorni.

Data Rate

 Latenze (forse il parametro più importante)

Gli ultimi due mesi abbiamo deciso di invalidare la garanzia e mettere mani direttamente al sistema linux. Abbiamo fatto decine di cambiamenti e soprattutto centinaia di test in ogni condizione e con ogni variazione possibile ed immaginabile, sia lato vmware sia lato SAN. Abbiamo prodotto più fogli excel e grafici di quanto avrei voluto, ma lavorando molto sull'utilizzo corretto della RAM dello storage intesa come cache, coinvolgendo il supporto al controllo SIOC di vmware, utilizzando la vFlash (features comunque così costosa da non avere un senso ed una applicabilità reale con apparati SAN così economici) e apportando una marea di variazioni, siamo riusciti ad avere il massimo matematico che potevamo ricavare da quell'hardware. Sufficiente? Dipende ovviamente da cosa ci deve girare e dalla mole di lavoro che hanno le VM.

Credeteci, abbiamo fatto innumerevoli test. Questo articolo tuttavia non vuole fare una statistica degli storage più o meno performanti, quindi marchi e modelli sono stati oscurati. Lo scopo è solo capire se uno storage "software" top di gamma può arrivare a performance similari ad uno "hardware" entry level.

Dopo quasi un anno di lavoro e di test, queste sono le mie personalissime conclusioni

Storage economici possono essere utilizzati solo per sistemi di backup, tipicamente con scritture relativamente sequenziali, impegnative come throughput ma meno sensibili a latenze elevate. 

In ambienti di produzioni, onestamente, dopo aver subìto macchine corrotte e dopo il tempo e gli sforzi che sono serviti ad avere un prodotto stabile e al limite dell'accettabile, non consiglierei questa soluzione nemmeno al mio peggior nemico. Vada per gli ambienti di test, vada anche per un paio di Domain Controller, ma per metterci database o fileserver ci vuole tanto coraggio. E nei miei test non ho usato proprio una macchinetta, ho preso il massimo, equipaggiato con il massimo delle opzioni ed i dischi più enterprise che il mercato SATA offriva.

Sostanzialmente, per quanto abbia tentato con tutte le mie forze e sperato di avvicinare uno storage "software" ad uno con hardware dedicato e specifico per questo scopo, le differenze sono e rimangono abissali ed i costi rispecchiano, in conclusione, esattamente i risultati ottenuti.

Senza considerare che le soluzioni hardware consentono solitamente anche la ridondanza a caldo dei controller ed hanno mediamente un bacino di clientela enterprise, con un livello di supporto decisamente migliore.