Li riconoscete?

Debian SSL fake e Metasploit: come ti costruisco una Rainbow table di chiavi private

Raffaele segnala che quelli di Metasploit hanno pubblicato i primi tool di cracking che sfruttano la vulnerabilità SSL di Debian vista nei post precedenti. Visto che lo spazio è limitato a 32767 chiavi, basta generare tutte le possibili chiavi private in questo spazio e poi confrontare le corrispondenti chiavi pubbliche con quelle dei sistemi con SSL bacato.

Insomma una sorta di Rainbow Table per le chiavi private!

Interessante anche che Verysign tranquillizzi i suoi utenti sul fatto che i loro certificati root e intermedi sino stati generati in modo sicuro (e ci mancherebbe!). I clienti sono comunque caldamente consigliati, nel caso abbiano utilizzato una distribuzione Debian, a rigenerare le coppie di chiavi e richiedere un nuovo certificato alla stessa Verysign senza costi aggiuntivi per il cliente.

Comunque rigenerate tutte le chiavi sulle vostre distro Debian e sperate che nessuno vi abbia sniffato il traffico cifrato, perché con questi crack potrebbe riattivarsi e cercare di di individuare la chiave di sessione negoziata con le chiavi fallate.

Animazione flash sull'algoritmo di cifratura di Rijndael (AES)

Vi segnalo questa animazione Flash sul cifrario di Rijndael. E' l'algoritmo di cifratura che ha vinto il contest AES.

http://www.formaestudio.com/rijndaelinspector/archivos/rijndaelanimation.html

Grave vulnerabilità nell'SSL/SSH delle distro Debian/Ubuntu

Il generatore random del package Debian di OpenSSL genera numeri altamente predicibili. Questa pericolosa vulnerabilità è presente nei package delle Debian based dalla versione 0.9.8c-1 (settembre 2006) e quindi anche sulle distribuzioni derivate tipo Ubuntu.

Per ovviare a tale problema bisogna prima di tutto eseguire un update del package e poi rigenerare tutte le chiavi utilizzate per gestire per esempio SSH, certificati X.509, etc. Si avete letto bene rigenerare tutte le chiavi...

Il post comparso su Slashdot ha ovviamente scatenato una serie di polemiche inevitabili sul fatto che la vulnerabilità sia stata introdotta da un solerte packager del gruppo Debian, che ha commentato delle righe di codice necessarie per la generazione casuale dei numeri di OpenSSL.

Il packager, utilizzando Valgrind, un prodotto per l'analisi della qualità del codice, sul package OpenSSL e rilevando un potenziale problema su un buffer di memoria non inizializzato, ha pensato che fosse un errore e ha prontamente commentato le righe di codice incriminate dai sorgenti del package!

Peccato che quel buffer non-inizializzato fosse la "fonte" random con la quale OpenSSL generava i numeri casuali. Commentando quel codice si è di fatto reso molto più predicibile il numero pseudo-randomico generato da SSL.

In conclusione, un falso positivo segnalato da Valgrind unito alla scarsa conoscenza di OpenSSL da parte del packager e alla sua poca prudenza, hanno generato una vulnerabilità molto grave e difficile da individuare (guardate la data della segnalazione...)

OWASP Day II italiano: luci e ombre

Dopo aver letto molti post di illustri colleghi che magnificavano l'OWASP Day II, mi sono deciso a scriverne uno anche io. Ho partecipato a tutta la giornata del convegno e ho avuto modo di vagliare uno per uno gli interventi.

Il convegno, con luci ed ombre, ha avuto interventi di sicuro rilievo ma purtroppo alcuni (non molti) sono stati assolutamente insufficienti. Il chairman, Matteo Meucci, da lodare per l'impegno che mette nell'organizzazione di questi eventi, è però da redarguire amichevolmente per due aspetti:

• più carattere nel dirigere questi convegni, cercando di acquisire più carisma anche nella moderazione degli interventi (ci sono stati interventi che sono continuati per un'ora...)
• una selezione più rigida degli interventi, magari con l'apporto di revisori esterni (qualche intervento era insufficiente anche per una tesina all'Università...)

Per quello che riguarda gli interventi, ecco le mie opinioni confortate spesso dai commenti della platea (anche autorevole):

• "L'approccio di Telecom Italia allo sviluppo sicuro delle applicazioni" di Marco Bavazzano (CISO TELECOM Italia): polpettone terribile sul ciclo di vita sicuro del software e di come Telecom sia leader in questo settore. Nulla di nuovo, argomentazioni trite e ritrite, slide orribili, molto marketing. Anche Telecom si è buttata in questo affare della Sicurezza Applicativa. Intervento assolutamente inutile.


• "SQL Injection tricks: building the bridge between the Web App and the Operating System" di Alberto Revelli (Portcullis Computer Security): bravo non c'è che dire; ha saputo gestire il suo intervento creando anche suspense e aspettative verso la tecnica di hacking (anche abbastanza innovativa) proposta. MetaSploit lo conoscono in molti, ma con mia grande sorpresa, qualche "esperto" della platea ancora lo ignorava...forse tanto esperto non è ;-) Comunque Alberto è stato molto bravo. Sicuramente un bell'intervento.


• "Le problematiche di Web Application Security: la visione di ABI Lab" di Matteo Lucchetti (ABI Lab): un disastro. Slide incomprensibili. Esposizione terribile. Spero per lui che fosse l'emozione. ABI dovrebbe presentarsi con persone in grado di reggere una conferenza anche sotto l'aspetto espositivo e di comunicazione. I contenuti erano assolutamente non fruibili, vista l'impossibilità di comprendere lo speaker. Si è dilungato 30 minuti oltre il tempo...Pessimo.


• "OWASP Backend Security Project" di Carlo Pelliccioni (Spike Reply): esposizione non male, forse un po' scolastica, ma contenuti insufficienti. Tecniche di SQL Injection veramente banali con esempi a dir poco sconcertanti. Secondo voi una SQL Injection in una banca riesce a cambiare la disponibilità di soldi nel vostro conto corrente? E' abbastanza ingenuo pensare che non vi siano meccanismi di controllo e quadrature che rilevino le anomalie. E' anche abbastanza ingenuo che in una banca vi sia una Web Application direttamente connessa allo strato dati. Molte persone della platea si sono spazientite nel vedere un intervento così banale. Intervento pessimo, ma incoraggiamo il giovane.


• "Web Services and SOA Security " di Laurent Petroque (F5): niente di particolarmente innovativo ma capacità espositive notevoli. Un bell'intervento, gradevole e con uno speaker preparato a gestire platee così ampie. Buon livello.


• "How to start a software security initiative within your organization: a maturity based and metrics driven approach." di Marco Morana (OWASP USA Chapter Lead, TISO Citigroup): Morana è un esperto e si vede. Ineccepibile sotto ogni punto di vista. Esperienza e capacità di esporre impeccabile. Intervento eccezionale senza alcun dubbio. Dimostra il suo valore anche nella tavola rotonda che praticamente gli ruota attorno.


• "Secure Programming with Static Analysis" di Jacob West (Head of Fortify Software's Security Research Group): un intervento tecnico assolutamente di alto livello. Jacob è preparatissimo e non poteva essere altrimenti. E' infatti l'autore insieme a Gary McGraw di "Secure Programming with Static Analysis" e anche di SCA di Fortify. Esposizione impeccabile da una persona abituata a fare interventi in conferenze. Intervento di altissimo livello.


• "The Owasp Orizon project: internals and hands on" di Paolo Perego (Spike Reply): bravo Paolo. Risolleva le sorti del capitolo italiano di OWASP. Intervento interessante centrato tutto sul progetto di cui è leader e ideatore. Progetto sicuramente interessante che vi consiglio di seguire. Ottime capacità espositive. Ottimo intervento.


• "Internet Banking and Web Security" di Giorgio Fedon (Minded Security): purtroppo non ho avuto modo di seguire il suo intervento, ma dalla tavola rotonda si vede che è persona acuta e abituata a gestire il contraddittorio.

Tavola rotonda:

Oltre a Raul Chiesa che ha dispensato i suoi soliti consigli da Hacker attempato, Matteo Flora ha fatto il suo show. Giorgio Fedon ha polemizzato con lui in modo costruttivo sulla Full Disclosure e, sebbene Matteo F. sia "animale" da "palcoscenico", il buon Giorgio ha vinto ai punti. Marco Morana poi dominava come figura GURU straripante di esperienza.

Matteo F. sei giovane per fare l'evangelist-showman all'americana ;-)

In conclusione un bell'evento ma con luci ed ombre. La sede e l'organizzazione logistica, gentilmente offerte dall'Università e dal gruppo di sicurezza del Dipartimento di Informatica, sono state comunque all'altezza. Forse è mancata solo un pò di maturità da parte del capitolo italiano di OWASP. Maturità che invece si è manifestata prepotentemente da parte di OWASP USA.

Continuate però a seguirli perché sicuramente faranno grandi cose. Sono giovani ma con un enorme potenziale.

Password in cassaforte e trust model di PKI e PGP

Non ho nulla in contrario al caro vecchio metodo della busta di carta con password di accesso a sistemi critici, chiusa con la ceralacca e messa in cassaforte. Ma nel 2008 ci sono sistemi più moderni!

Immaginiamo uno scenario, tipicamente di Business Continuity Planning (BCP), in cui particolari utenti, in condizioni critiche, debbano poter accedere a credenziali riservate. Come possiamo progettare una infrastruttura informatica che permetta ciò, rendendo l'accesso veloce e sicuro al tempo stesso?

Potremmo usare PGP o GnuPG nella sua versione FOSS e delineare due processi:

Processo di inizializzazione dell'infrastruttura di cifratura e firma

• Installazione sulle macchine degli utenti selezionati di una versione di PGP o GnuPG: Gpg4win su Windows o GnuPG su Linux & Windows o, se avete voglia di spendere soldi, PGP;
• Per ogni utente, creazione di una coppia di chiavi PGP; la passphrase di accesso alla chiave privata sarà scelta dallo stesso utente e dovrà rispettare alcune caratteristiche di sicurezza: complessità, lunghezza minima, lunghezza massima (per attacchi di tipo social engineering), etc.;
• Definire una gerarchia delle chiavi PGP in relazione alla gerarchia aziendale; ricordo che il trust model di PGP è diverso da quello delle PKI (ma lo vedremo più avanti);
• Firmare le chiavi pubbliche PGP degli utenti in un determinato livello gerarchico con quelle del livello superiore;

Processo per la cifratura del file delle credenziali

• Memorizzare, in un ambiente sicuro e con una macchina sicura, un file di testo con le password critiche e cifrare tale file con TUTTE le chiavi pubbliche PGP degli utenti che vi dovranno accedere in caso di emergenza;
• Far firmare il file cifrato dagli utenti di livello superiore con le loro chiavi private PGP;
• Depositare il file cifrato e firmato in una condivisione di rete il cui accesso è monitorato e tracciato (dobbiamo sempre sapere chi accede e quando);
• Introdurre della ridondanza depositando il file anche su diversi supporti quali chiavi USB da consegnare ad ogni utente di livello superiore (che terrà traccia delle richieste di tali supporti), oppure in modo analogo su CD-ROM;
• Infine depositiamo il CD-ROM e la chiave USB in cassaforte ignifuga insieme alla cara e vecchia busta cartacea.
• Ad ogni accesso al file cifrato dovranno seguire necessariamente una rigenerazione delle password e una nuova procedura di cifratura e distribuzione.

Quali possono essere i problemi in uno scenario simile?

• ogni utente dovrà avere sempre a disposizione la propria coppia di chiavi PGP e un software per operarvi;
• ogni utente dovrà custodire in modo appropriato la propria coppia di chiavi e la passphrase di accesso alla chiave privata;
• ogni utente di livello superiore dovrà custodire con cura gli eventuali supporti magnetici con il file cifrato;
• dovrà essere sempre tenuta traccia degli accessi degli utenti autorizzati alle credenziali cifrate, siano esse depositate su share di rete che su supporti magnetici in luoghi fisici;
• le password di accesso ai sistemi devono essere cambiate in modo ciclico e il processo di cifratura deve essere ripetuto ex-novo;
• i file decifrati debbono essere cancellati SEMPRE ed in modo sicuro;

Abbiamo parlato di PGP e di coppie di chiavi pubblico/private, ma allora che differenza c'è con una PKI (Public Key Infrastructure)?

Le PKI implementano un modello di trust che prevede delle autorità terze e fidate chiamate Registration Authority (RA) e Certification Authority (CA), le quali garantiscono un certificato identificandone il possessore in modo certo e firmandolo. Queste autorità sono organizzate in una gerarchia che diviene poi la catena di trust di un certificato pubblico. La catena di trust è la sequenza di certificati nella gerarchia, fino ad arrivare a quello dell'utente, in cui ogni certificato fidato è firmato dal precedente (fidato) e firmerà il successivo.

Una CA radice quindi firmerà il certificato radice di una CA subordinata, che a sua volta firmerà altre CA subordinate e così via, fino ad arrivare alla firma di un certificato utente per la firma di documenti, cifratura di mail, etc.

Questa gerarchia di enti certificatori introduce però una certa rigidità nella gestione dei certificati, che influisce in modo non sempre positivo nei processi aziendali legati ai certificati.

Un modello di trust differente è quello implementato da PGP o GPG: il Web of Trust.

Questo modello prevede che il certificato pubblico PGP sia firmato da altri utenti in possesso di una coppia di chiavi PGP in delle "riunioni di firma". Il trust della chiave pubblica è quindi implicato dalla fiducia che si attribuisce alle diverse persone che hanno firmato il certificato. Si procede in modo ricorsivo anche per la fiducia attribuita a tali firmatari.

Quali sono le differenze tra i due modelli?

Supponiamo di avere due certificati rispondenti ai due diversi modelli di trust: PKI e PGP.

Nel caso delle PKI il trust di un certificato utente è inferito dal certificato CA o subCA che lo ha firmato e che compare nella catena di trust contenuta nel certificato utente.

Qualsiasi utente potrà verificare il trust ripercorrendo la catena di trust e verificando che l'impronta del certificato radice CA al vertice della catena sia effettivamente valido (problema dei certificati fake). Nel caso quindi di PKI ci "fidiamo" dei "notai" esterni come le CA e verifichiamo che la loro firma sia sempre valida.

Nel caso di PGP, l'utente in possesso del certificato e della coppia di chiavi PGP, richiederà di firmare la propria chiave pubblica ad amici e conoscenti che, così facendo, aumenteranno il trust del suo certificato. Quando qualcuno vorrà verificare il trust di un certificato potrà analizzare gli autori delle firme, verificando per ognuno di essi il loro trust e così via, fino ad arrivare ad una persona conosciuta o di cui si fida.

Dati sensibili e strutture sanitarie: un caso di studio (terribile)

Questa storia ha un protagonista: Mario.

Mario si reca in una grande struttura pubblica per fare degli esami sanitari sulla sua condizione di salute. Gli viene consegnato un foglio in cui si dice che il risultato delle analisi verrà consegnato unicamente a lui o, in alternativa, ad un suo delegato munito di documento di riconoscimento.

"Bene!" pensa tra sé e sé (illuso...)

Gli esami sono pronti e Mario, solerte, si reca nella grande struttura, gironzola un po' prima di trovare la fatidica stanza e bussa alla porta:

• Mario: "E' permesso? dovrei ritirare i risultati delle mie analisi per XXXXXXX"
• Infermiera: "Come si chiama?"
• Mario: "Mario Esposito"
• L'infermiera: "Aspetti che cerco..."
• Mario (balbettando quasi incredulo) "ma...le devo dare il documento?"
• L'infermiera: "No no. Ecco a lei la busta con i risultati delle analisi" (busta rigorosamente aperta)

Ma dico io, possibile che ancora succedano queste cose?

Mario sta scrivendo una bella lettera alla Direzione Sanitaria e in copia al Garante per la Privacy.