Sull’usabilità nella sicurezza

Uno degli errori più comuni che chi si occupa di sicurezza, soprattutto nelle piccole e medie realtà, commette è quello di ignorare che la sicurezza riguarda principalmente le persone.

La sicurezza nasce sempre dalla collaborazione tra utente e amministratore che potrà prendere tutte le misure possibili ma saranno gli utenti (consapevolmente o meno) a decidere in che modo e in che misura utilizzarle. In molte situazioni questa collaborazione non viene curata e spesso addirittura evitata. Non si cura ne l’educazione alla sicurezza dell’utente ne l’interfaccia utente delle varie infrastrutture di sicurezza. Ci si dimentica che la sicurezza è effettiva solo quando viene usata correttamente, in genere si verifica una situazione simile:

Semplificando molto l’analisi: nel grafico la linea blu è la situazione ideale ovvero aumentando le misure di sicurezza adottate aumenta proporzionalmente la sicurezza effettiva del sistema e diminuisce l’usabilità; la linea arancione è la situazione reale, ad un certo punto maggiori misure di sicurezza non porteranno a miglioramenti della sicurezza effettiva.
Per spiegare questa anomalia bisogna tenere conto che sicurezza e usabilità sono inversamente proporzionali, quello che accade è che ad un certo livello il sistema diventa non sufficientemente usabile per l’utente medio. È il fattore umano il più grande limite alla sicurezza.

Un esempio banale: consideriamo tre sistemi di autenticazione, S1 che prevede l’utilizzo di una sola password per accedere alle risorse, S2 che prevede 2 password e S10 che ne prevede 10. In un ambiente ideale il sistema S10 sarà 10 volte più sicuro del sistema S1. Nella realtà invece l’utente medio difronte a S1 sceglierà una password più o meno robusta, difronte al sistema S2 molto probabilmente ne sceglierà due uguali (il livello di sicurezza rimane dunque invariato rispetto a S1) e infine difronte a S10 difficilmente ne sceglierà dieci diverse ma molto probabilmente ne sceglierà solo una lasciando le successive bianche e anche in questo caso il livello di sicurezza è pari a quello di S1.
Ecco un altro esempio dove l’adozione di un meccanismo di sicurezza è controproducente. Consideriamo un’applicazione che permette all’utente di bloccare tutti i dispositivi (lettore cdrom, floppy, porte USB, infrarossi, etc.) per evitare il furto di dati. Supponiamo che l’applicazione prevede che per bloccare e sbloccare i dispositivi occorre inserire ogni volta la password di sistema (quella utilizzata dall’utente per accedere a Windows) e supponiamo anche che l’operatore debba bloccare la macchina (inserendo la password) ogni volta che si allontana dalla postazione e successivamente sbloccarla (inserendo nuovamente la password). Il risultato finale sarà che l’utente modificherà la password di accesso scegliendola più corta possibile o comunque banale per velocizzare le operazioni di bloccaggio/sbloccaggio dei dispositivi. Avremo dunque diminuito il grado di sicurezza generale poiché la macchina e l’applicazione saranno protette da una passwword debole. In una situazione simile si possono trovare più errori: nel comportamento dell’amministratore che ha imposto misure di sicurezza eccessive o non ha saputo illustare ai suoi utenti la necessità di una tale misura; nell’applicazione che invece di usare una propria password usa quella di accesso.

La soluzione sta nel trovare un giusto equilibrio tra usabilità e sicurezza. Equilibrio che deve tener conto dell’effettiva necessità di sicurezza e del livello degli utenti (eventualmente da adeguare alle necessità). Oppure si dovrebbero adottare, ogni volta che è possibile, soluzioni centralizzate e automatizzate in modo da tener lontano l’utente dalla gestione della sicurezza.
Lo stesso discorso, ma in altri termini e con altre soluzioni, vale per gli sviluppatori di software che scrivono le loro applicazioni in modo che possano essere usate nel rispetto di tutte le norme di sicurezza ma saranno gli utenti a decidere in che modo utilizzarle.

P2P: il vero nemico della privacy

Riprendendo il discorso sull’importanza dei client nella messa in sicurezza di una rete va evidenziata l’importanza delle applicazioni P2P che contribuiscono in almeno due maniere all’insicurezza di un host:

• vulnerabilità insite nell’applicazione
• misconfigurazione e/o utilizzo non consapevole

Inoltre c’è da evidenziare anche il fatto che le reti P2P di nuova generazione sono difficilmente individuabili e isolabili.
Oltre a questo bisogna prendere in considerazione tutte le problematiche relative alla violazione dei copyright e all’utilizzo indiscriminato della banda (data la sua natura il P2P, se non limitato, in breve tempo prende possesso di gran parte della banda disponibile).

E` interessante soprattutto il secondo aspetto riguardante la non configurazione delle applicazioni P2P. Il problema è che queste applicazioni vengono spesso installate e configurate da utenti che ignorano completamente i concetti base delle reti e le minime misure di sicurezza. Spesso viene mantenuta la configurazione di default che in genere è molto permissiva per permettere il funzionamento in gran parte delle situazioni possibili, altre volte viene azzardata una configurazione che se è possibile peggiora ancora di più la situazione.

Uno dei misfatti più comuni è la condivisione dell’intero disco o di intere cartelle come Documenti e simili. E` di poche settimane fa lo studio della Tiversa Inc. che ha rilevato che sulla rete Limewire, ma non solo, sono in condivisione una gran quantità di documenti riservati del governo statunitense messi in condivisione da impiegati dei vari enti e agenzie.
Il CEO del Lime Group sottolinea che spesso queste condivisioni oltre che inconsapevoli sono anche involontarie in quanto indotte da malware nascosto, scaricato insieme a file regolari, che ha la funzione di indicizzare l’intero hard-disk.

Per curiosità ho fatto delle prove utilizzando le reti eDonkey, Slsk e Gnutella e in meno di mezz’ora di ricerca il risultato è stato allarmante, ho individuato:

• hard-disk di una macchina interna alla rete del comune di Firenze interamente condiviso; e quindi archivi, lettere, incarichi, deleghe, appalti e dati personali in grande quantità;
• cartella documenti condivisa di un commercialista di Milano con tanto di bilanci, contratti, bonifici, lettere a banche e Ministeri vari, estratti conto di clienti che ignorano che i loro dati sensibili circolano liberamente per la rete;
• intero hard-disk di un’azienda agricola di Taranto completo di fatture, dati sui clienti, contratti e dati di conti bancari.

Oltre a ciò viene fuori una grande quantità di coppie username/password di account email e di forum ma anche dati relativi a conti correnti online (c’è chi è stato capace di salvare i propri dati bancari in un file dal nome FileImportante-Dati-PostePay.txt) e dati personali (copie di carte d’identità, tessere sanitarie, codici fiscali, passaporti…). E ancora:

• file di configurazione dei browser web che ora permettono anche di salvare le password (non sono in chiaro ma facilmente decifrabili);
• file di configurazione di client IM/IRC con tanto di log e password;
• interi archivi email;
• copie di backup di siti internet con tanto di database contenente dati (email, numero di CC) degli utenti iscritti.

Insomma data la diffusione del P2P la situazione non è confortante. Vista la natura del problema la soluzione deve prevedere contromisure tecniche e soprattutto contromisure comportamentali. Senza entrare nei dettagli, per chi gestisce grandi reti (università, biblioteche, enti pubblici, etc.) vista l’importanza dei dati in ballo le contromisure devono essere drastiche: oltre a bloccare (nei modi e nelle misure possibili) il traffico P2P occorre definire una politica rigida sull’installazione di software e bisogna educare i propri utenti alla sicurezza.
Gli utenti domestici, a cui nessuno può negare l’utilizzo di applicazioni P2P, invece devono prendere coscienza dei rischi a cui vanno incontro con un utilizzo security-free del P2P.

PISA contro Skype

Ancora dal BlackHat 2007: PISA contro Skype o più precisamente Protocol Identification via Statistical Analysis per identificare i nuovi protocolli P2P.

Nelle applicazioni P2P si nota un’evoluzione determinata da cause non necessariamente tecniche. I protoccoli P2P si sono dovuti via via adeguare ai giri di vite dei legislatori e degli ISP e alle sempre più precise tecniche di rilevazione degli amministratori di rete. Il frutto di queste necessità è Skype, ovvero al posto dei vecchi limpidi protocolli dalle specifiche pubbliche si iniziano a vedere degli oscuri protocolli proprietari (Skype ne è il capostipite).

All’ultimo BlackHat, Rohit Dhamankar e Rob King della TippingPoint hanno presentato un sistema di identificazione basato sull’analisi statistica del traffico.
Gli autori partono dal presupposto che d’ora in poi i protoccoli P2P, ma non solo, faranno grande uso di crittografia e dunque le vecchie tecniche di identificazione basate sull’analisi del contenuto dei pacchetti scambiati risulteranno completamente inutili.
Il PISA rappresenta il traffico in uno spazio a 10 dimensioni i cui assi sono: la dimensione media dei pacchetti verso il client e verso il server, i tempi di risposta, sulla deviazione standard dei suddetti parametri e sulla differenza di traffico tra server e client e infine l’entropia di Shannon. Quest’ultima viene utilizzata per determinare se il protocollo usa una qualche forma di crittografia oppure dati in chiaro.
La sperimentazione per questo sistema è stata condotta cercando di venire a capo di uno dei grandi problemi degli amministratori di rete: separare il traffico Skype da tutto il resto. Gli incoraggianti risultati, basati sulle proprietà statistiche dei protocolli, hanno stabilito che è possibile identificare il traffico prodotto da Skype, con un minimo errore, analizzando solo 600 pacchetti (ovvero circa 1,5 secondi di chiamata).

L’approccio è sicuramente interessante ma bisogna valutare, come al solito in queste situazioni, i falsi positivi generati da una simile analisi. Il codice non è ancora disponibile, quindi non ci resta che attendere sintonizzati su http://dvlabs.tippingpoint.com/projects/PISA

Da citare: statistics is like a bikini that reveals what is interesting and hides what is vital.

Un nuovo approccio ai penetration test

I tizi di Metasploit hanno presentato, a BlackHat 2007, un nuovo (ma non troppo) approccio al penetration testing. Il metodo presentato (Tactical approach) si basa sul presupposto che le vulnerabilità sono transitorie e che i veri bersagli sono le applicazioni, i rapporti di fiducia, i processi e soprattutto le persone.

Gli autori introducono il concetto di meatware come elemento centrale della fase di raccolta delle informazioni poiché sono le persone a scrivere il software, ad installarlo, a configurarlo e a gestirlo. Quindi il primo passo consiste nel recuperare informazioni su coloro che hanno creato e che gestiscono tutte le infrastrutture da testare. A tale proposito citano un interessante tool da utilizzare per recuperare da internet tutte le informazioni e le relazioni relative a una persona o a un dominio, si tratta di Evolution della Paterva.com.
A proposito invece del network discovery citano, oltre ai classici tool, il sito DomainTools come fonte pricipale di informazioni. Dopo le persone e le reti l’approccio tattico prevede una fase di application discovery perché “se le reti sono i toast, le applicazioni sono il burro”… in questa fase i tool utilizzati sono i classici Nmap, Amap, Nikto e Nessus. Da citare una frase sul port scanning che ogni pentester dovrebbe mandare a memoria: “A slow, single port scan is able to evade common defensive measures. Slow and steady wins the deface. Scan for specific port, one port only.”. D’ora in poi nmap solo con -T0 contro una sola porta.
Dopo i server è il turno delle applicazioni client, e siamo alla fase client app discovery. Il presupposto è che ora i client, soprattutto i web browser e i programmi per la posta, hanno funzionalità che vanno oltre la visualizzazione delle pagine web e delle email. Inoltre i client sono quasi sempre vulnerabili, non è semplice per gli amministratori gestirne la sicurezza e sono anche facilmente identificabili da remoto. Infine l’ultima fase prevista per la raccolta di informazioni è quella di process discovery, ovvero tenere traccia di cosa fa il nostro bersaglio.

La seconda fase della presentazione riguarda l’utilizzo delle informazioni raccolte, vengono descritti attacchi al web server, al DNS server, ai CGI, in gran parte portati utilizzando la versione SVN di Metasploit, niente di particolarmente innovativo comunque.

In conclusione quello che gli autori tengono a sottolineare è che “Hacking is not about exploits. The target is the data, not r00t”. Dunque una rete sicura dalla quale è possibile recuperare/controllare importanti dati è una rete vulnerabile. Quindi un’intrusione, e anche un penetration test, possono dirsi riusciti non solo quando si ottiene un completo accesso alla rete…
Un altro elemento, sicuramente da approfondire, che viene fuori dal paper è l’inutilità dei penetration test improvvisati, fatti utilizzando i soliti noti tool che vorrebbero automatizare l’intero processo di testing.

Il mantra dell’intera faccenda, che andrebbe stampato ovunque, è
“Tools cannot replace talent”. Amen.

Proteggere i dati è obbligatorio

L’accesso a dati non protetti non è riconducibile ad un accesso non autorizzato… lo dice una sentenza di una corte della Pennsylvania (maggiori informazioni qui).

In pratica il giudice non ha rilevato da parte dell’attaccante nessuna violazione di eventuali protezioni (che erano effettivamente assenti o malfunzionanti) dei dati. Più precisamente l’accesso ai dati attraverso gli archivi dei motori di ricerca non prefigura una violazione delle leggi sul diritto d’autore e delle leggi anti-hacking. Nel caso in questione alcuni dati sensibili erano finiti per sbaglio (e in effetti in pochi sanno minimamente come funziona l’indicizzazione dei motori di ricerca) negli archivi di un motore di ricerca e da questa cache erano stati prelevati dall’attacker che secondo il giudice non è colpevole poiché i dati non erano stati protetti, e quindi inconsapevolmente resi pubblici, dal legittimo proprietario.

La lezione è: bisogna stare attenti a cosa si mette nel file robot.txt, ovvero a cosa si permette al motore di ricerca di archiviare e indicizzare.
O anche: se metti a disposizione dei motori di ricerca dei dati sensibili e io me li prendo il problema è solo tuo…