Ci risiamo: ecco #DROWNAttack

Sono passati dodici mesi da quando il cosiddetto FREAK Attack ha scatenato il panico su internet: oggi parliamo di un altro rischio nella sicurezza di portata simile.

Si chiama DROWNAttack, ovvero Decrypting RSA with Obsolete and Weakened eNcryption, è un attacco che sfrutta una debolezza nella versione 2 del protocollo SSL. Questa debolezza non è frutto di un errore, ma di una scelta progettuale dovuta alle restrizioni esistenti negli anni ’90 sulla esportazione di tecnologie crittografiche dagli USA verso l’estero. La storia di come queste restrizioni siano state concepite e di quale danno abbiano provocato dovrebbe essere già noto a tutti, segnalo comunque al lettore interessato la esaustiva pagina su Wikipedia.

Il funzionamento di DROWN è spiegato in questo documento tecnico completo, tuttavia riassumeremo qui di seguito il suo modus operandi a grandi linee. Leggi tutto “Ci risiamo: ecco #DROWNAttack”

Let’s Encrypt

Let's EncryptIeri è partita la beta pubblica di Let’s Encrypt.

Il sito rilascia gratuitamente, senza se e senza ma, certificati TLS firmati da una CA riconosciuta dalla PKI, con l’eccezione di Windows XP.

In altre parole, i certificati di Let’s Encrypt sono riconosciuti dai browser, possono essere utilizzati senza problemi dalle società e se ne possono prendere un numero arbitrario. Leggi tutto “Let’s Encrypt”

Freestart collision di SHA-1

SHA-1 è un algoritmo di hash, ovvero un algoritmo che trasforma una serie di dati di lunghezza arbitraria in una serie di dati di lunghezza fissa.

In crittografia una buona funzione di hash non deve permettere di dedurre i dati sorgente conoscendo solamente il risultato e non deve permettere facili collisioni, ovvero dato un risultato, trovare una sequenza di dati che fornisca quel preciso valore di hash.

Le funzioni di hash utilizzate in crittografia cambiano con l’evolversi della potenza computazionale a disposizione. MD5 è stato reso obsoleto da tempo, ora è il turno di SHA-1 perché la sua vulnerabilità è una cosa nota da qualche tempo.

Con un hardware attuale normalmente acquistabile si può calcolare una collisione SHA-1 in una settimana circa. Leggi tutto “Freestart collision di SHA-1”

SSL/TLS da command line

8Spesso potrebbe tornare utile effettuare dei test delle connessioni SSL/TLS da linea di comando *NIX senza scomodare un browser o un client del protocollo che si vuole verificare.

Di seguito alcuni esempi di come effettuare queste verifiche. Leggi tutto “SSL/TLS da command line”

SHA-1

La crescita della potenza di calcolo crea problemi ai vecchi algoritmi di sicurezza o di hash.

L’algoritmo MD5 era stato reso obsoleto a fine 2008, ora è il turno di SHA-1.

Il protocollo https fa un ampio uso degli algoritmi di hash, ma se è relativamente facile calcolare delle collisioni che permettono di calcolare il dato originale partendo dall’hash, la sicurezza di https è compromessa. Leggi tutto “SHA-1”

Attenzione al #FREAKAttack

FREAK è l’acronimo di Factoring RSA Export Keys.
Si tratta del termine con cui si identifica un exploit di sicurezza, relativo alle chiavi pubbliche e private di una comunicazione crittografata, venuto alla ribalta solo ai primi di marzo del 2015, nonostante si basi su una vulnerabilità risalente a decenni fa. Leggi tutto “Attenzione al #FREAKAttack”

Risolvere gli errori delle CA intermedie

Sempre più siti adottano certificati validati dalla PKI, grazie anche a fornitori molto convenienti.

Alcuni certificati acquistati necessitano di una serie di CA oppure di certificati intermedi affinché il client li possa verificare correttamente.

Esistono tool online come quello di SSL Hopper che permettono di verificare se il server dichiara correttamente la catena di certificati che validano quello che si sta utilizzando. Leggi tutto “Risolvere gli errori delle CA intermedie”

FTPS con vsftpd

Il protocollo FTP è, a ragione, abbastanza disprezzato dai SysAdmin.

Siccome è un protocollo molto vecchio, presenta dei comportamenti che non sono più adatti alle configurazioni attuali. Uno di questi è la trasmissione in chiaro delle credenziali.

Come per altri protocolli, è stata aggiunta la possibilità di utilizzare TLS come trasporto ottenendo il protocollo FTPS (RFC4217), che non va confuso con il protocollo SFTPLeggi tutto “FTPS con vsftpd”

File dei certificati SSL

Più studio i dettagli e i dietro le quinte di SSL/TLS e della PKI e più mi rendo conto di quanti (troppi?) livelli di complessità ci siano in questo insieme di tecnologie.

Tra questi ci sono i formati dei file e le loro estensioni.

Anche in questo caso vale la regola che il bello degli standard è che ce ne sono tanti tra cui scegliere.

Ho cercato di mantenere il discorso il più chiaro possibile linkando fonti esterne per evitare di aprire troppi incisi; l’elenco e le spiegazioni sono tutto fuorché esaustivi. Leggi tutto “File dei certificati SSL”

SNI su Apache 2.4

L’adozione di https sta diventando sempre più importante per la tutela della privacy degli utenti e per la sicurezza delle comunicazioni.

Uno dei fattori che più hanno limitato la diffusione di questo protocollo risiede nella caratteristica della sessione TLS che, fino a poco tempo fa obbligava ad avere un solo certificato PKI per una coppia IP:porta. Leggi tutto “SNI su Apache 2.4”

Microsoft Secure Channel

Con l’aggiornamento del patch tuesday di questo mese Microsoft corregge un problema di sicurezza molto serio di Secure Channel (Schannel), la sua libreria per la connessione sicura.

Schannel è per Microsoft quello che per l’open source si chiama OpenSSL e per Apple si chiama Secure Transport. In sostanza è quella serie di routine (libreria) che permette di stabilire connessioni sicure in HTTPS o TLS. Con l’annuncio della vulnerabilità di Schannel si può affermare che quest’anno ciascuna delle maggiori librerie HTTPS/TLS ha avuto dei problemi, con buona pace di chi crede di essere al sicuro per il fatto stesso di utilizzare una piattaforma piuttosto che un’altra.

Schannel è utilizzato dai client e dai server che stabiliscono o accettano connessioni sicure utilizzando le funzioni di sistema di Microsoft.

La vulnerabilità segnalata e corretta da Microsoft permette di eseguire codice arbitrario da remoto. In altre parole, un attaccante potrebbe eseguire dei programmi che vuole lui su un computer che utilizza Scannel per collegarsi ad un altro computer. I primi (ma non di certo gli unici) membri di questo insieme sono tutti i Windows che hanno un Internet Information Server esposto a Internet con HTTPS abilitato. A titolo di pro memoria, Exchange Server utilizza HTTPS per far connettere i client mobili. Leggi tutto “Microsoft Secure Channel”

POODLE

POODLE (Padding Oracle On Downgraded Legacy Encryption) è un tipo di attacco alle connessioni https in grado di rubare informazioni sensibili, incluse, teoricamente, le password degli account.

L’attacco si basa su una vulnerabilità di SSLv3, RFC6101, un protocollo del novembre 1996 poco sicuro che fa parte del gruppo di protocolli di scambio dati previsti da https e da tutti i protocolli che usano TLS, come IMAPS, POP3S, SMTP con STARTTLS, eccetera.

Quando viene iniziata una connessione TLS client e server confrontano i protocolli supportati e negoziano il più sicuro tra quelli supportati da entrambi. Tuttavia è anche possibile che un attaccante in grado di disturbare la connessione tra client e server riesca a forzare usa sessione con il protocollo meno sicuro. Leggi tutto “POODLE”

Prima versione di LibreSSL

LibreSSLÈ stata rilasciata la prima versione di LibreSSL, aggiornata oggi alla 2.0.1.

LibreSSL si propone come rimpiazzo di OpenSSL dopo i problemi iniziati con heartbleed. Il team di BSD ha avviato il progetto con l’intenzione di produrre un codice meno fumoso, più stabile e sicuro.

Il codice di OpenSSL ha sulle spalle una lunga storia di compatibilità verso il basso che ha trasformato il codice in qualcosa di poco gestibile e prono agli errori.

LibreSSL ha tolto di mezzo la compatibilità con piattaforme non più utilizzate in produzione, come MS-DOS, VMS, NetWare, Windows a 16 bit, Windows NT e OS/2 e con essa un sacco di problemi.

Di fatto OpenSSL utilizza un C compatibile con ogni compilatore possibile da quello dell VMS al QuickC 1.5 all’ultimo gcc, con il risultato che deve reinventare al proprio interno il fuoco, la ruota e l’acqua calda. Una delle conseguenze di tutto ciò è che OpenSSL ha una propria libreria di allocazione della memoria che non è controllabile dal sistema operativo o dai normali tool di debug, ma ha una propria serie di API per fare il debug della gestione della memoria.

Leggi tutto “Prima versione di LibreSSL”

OpenSSL e software open

Piazza PetrarcaSono state scoperte e corrette altre sei vulnerabilità di OpenSSL. Enfasi su “corrette”.

Dopo Heartbleed qualcuno ha dubitato della bontà del software open, altri hanno visto quel problema come un argomento a favore di una circolazione limitata dei sorgenti.

Sono argomenti facilmente confutabili con l’esperienza della storia e le basi della sicurezza informatica.

Il problema non è la differenza tra software open e no, ma tra programmi scritti bene e programmi scritti male, senza coerenza e con un sacco di scorciatoie pericolose. Entrambe queste categorie sono ben rappresentate sia nel software open sia nel software commerciale, le due tifoserie contrapposte ritengono che il peggio sia nella controparte. Leggi tutto “OpenSSL e software open”

SMTP STARTTLS in crescita

Sottopasssaggio con cavi / Subway with cablesUn rapporto di Facebook dimostra che la cifratura della posta elettronica ha raggiunto una “massa critica”.

Questa è senza dubbio una buona notizia per la tutela dei dati personali perché il normale protocollo SMTP, figlio di quando Internet era un’altra cosa, dialoga in chiaro.

L’estensione STARTTLS consente anche ad SMTP di passare ad una connessione cifrata utilizzando la medesima connessione TCP.

I dati presentati da Facebook evidenziano che tre quarti dei mail server con cui dialoga il social network supportano STARTTLS, anche se solamente poco più della metà delle mail vengono cifrate con successo. Leggi tutto “SMTP STARTTLS in crescita”

Heartbleed: anche le password

by heartbleed.comAncora su OpenSSL / Hearthbleed, i maggiori siti dovrebbero aver già predisposto gli aggiornamenti necessari a superare il problema. Adesso è il turno dei singoli utenti.

Una delle conseguenze di Hearthbleed è la possibilità che il traffico https sia stato intercettato e decriptato. Con esso pure le password per accedere ai singoli servizi. Le conseguenze sono ovvie.

Il consiglio a tutti gli utenti è quello di cambiare al più presto TUTTE le password di Home Banking, Facebook, Google, LinkedIn, PayPal, Amazon e di tutti i vari servizi in giro sul web a cui siete iscritti (specie quelli in cui c’è movimento di denaro o dati di carte di credito) perché potrebbero essere state compromesse. E’ difficile ma dobbiamo presumere per sicurezza che sia stato fatto.

Mai, mai, mai, mai utilizzare su questi siti una password che utilizzate anche per lavoro. MAI! Se craccano il servizio esterno mettete in pericolo pure l’infrastruttura dove lavorate. Se l’avete fatto in passato occorre cambiare anche quella password (supponendo che le regole interne non vi obblighino già a farlo regolarmente).

Mai, mai, mai, mai utilizzare la stessa password su più siti diversi. MAI! Se viene compromesso un sito possono (anzi lo fanno di sicuro) provare a vedere se lo stesso account è presente su altri servizi.

Ad esempio se vi catturano la password di Facebook che mettiamo sia uguale a (esempio assurdo) quella del vostro Home Banking pensate che di essere al sicuro?

Avere password differenti è importante, pensate al vostro portachiavi. Avete un unica chiave oppure una chiave per ogni porta che dovete aprire?

Per quanto riguarda la complessità della password… lasciamo stare la teoria che vorrebbe password lunghe chilometri con ghirigori, maiuscole, minuscole, numeri, simboli, giravolte, sbirigudi ed antani. Proteggiamo pesantemente  (magari con l’autenticazione multipla e con SMS di avviso) l’account che per voi è fondamentale. Quello su cui magari vi arrivano le notifiche dagli altri account e tramite il quale possono accedere agli altri servizi. Per gli altri servizi si può utilizzare una password più semplice da ricordare (ATTENZIONE: semplice non significa banale o completamente idiota) e magari dove disponibile attivare sempre l’autenticazione multipla.

Per fare un esempio recentemente è saltata fuori la storia di un giornalista a cui hanno rubato tutti gli account semplicemente perché sono riusciti ad introdursi nella sua posta elettronica. Una volta preso il controllo delle mail gli hanno cambiato le password di tutto, rubato gli account Twitter, Facebook, Google+ e i domini Internet dei propri siti web. Fate voi.

E se pensate “a me non succederà mai perché chi vuoi che mi attacca a me” siete le vittime perfette. Pensate che la maggior parte di questi attacchi non sono mirati ma fatti con script automatici. A loro non interessa chi siete ma solo i vostri account.

L’ho già detto “Mai, mai, mai, mai utilizzare su questi siti una password che utilizzate anche per lavoro. MAI!” ? Ve lo ridico giusto per essere sicuri.

Fine del pippone.

Heartbleed: non solo i server

by heartbleed.comQuando si parla di heartbleed quasi tutti pongono l’accento sulla falla di sicurezza dei server.

Ma le librerie OpenSSL sono utilizzate anche dai client, altrimenti chi si collegherebbe al server? 🙂

Anche qui stiamo parlando di programmi prevalentemente Linux/FreeBSD o comunque in genere dei porting da Linux/FreeBSD su altre piattaforme.

I programmi client utilizzano le stesse librerie e le stesse funzioni dei server. Tra questi si annoverano cURL e wget, molto utilizzati non solo dagli utenti per scaricare file, ma da molti script e programmi terzi per i medesimi scopi. Al di fuori del protocollo https, si può citare fetchmail.

La libreria OpenSSL è utilizzatissima da quasi tutti i programmi che implementano SSL/TLS.

È quindi essenziale che tutti aggiornino appena possibile OpenSSL ad una versione successiva la 1.0.1f, anche se non hanno server con abilitato https.

Aggiornamento 13 aprile 2014 – Uno script in Python permette di verificare se un client è vulnerabile.

Heartbleed

by heartbleed.comHeartbleed è il nome di una vulnerabilità molto seria scoperta sulla libreria OpenSSL dalla versione 1.0.1 alla 1.0.1f incluse.

OpenSSL è utilizzata per il traffico https da molti software, tra cui Apache e nginx che da soli costituiscono il 66% dei server web, anche se bisogna rilevare che non tutti i server web hanno https abilitato.

Microsoft Internet Information Server non è interessato da questo problema.

I prodotti Apple non sono interessati dal problema, con l’eccezione dell’AirPort per cui è disponibile un aggiornamento.

Tutto è cominciato nel 2012 con la release di OpenSSL 1.0.1 che introduce il supporto di RFC6520 e implementa l’heartbeat sulle connessioni TLS. Questa funzione serve a mantenere il canale aperto e impedire, quindi, che client e server debbano rinegoziare la connessione in caso di temporanea inattività. L’espediente dell’heartbeat o keep-alive è utilizzato in molti contesti in cui si invia un pacchetto dati senza informazioni con il solo scopo di resettare eventuali contatori di inattività.

Il problema di OpenSSL è che una riposta al’heartbeat modificata ad arte può rivelare all’attaccante informazioni di vario tipo. Non è possibile utilizzare questa vulnerabilità per eseguire codice sul server remoto, ma questo non è certo un fattore mitigante, vediamo perché. Leggi tutto “Heartbleed”

Testimonianza di Snowden al Parlamento Europeo

Lo scorso dicembre la Commissione per le libertà civili, giustizia e affari interni del Parlamento Europeo ha inviato ad Edward Snowden alcune domande nell’ambito dell’inchiesta sulla sorveglianza di massa dei cittadini europei.

Snowden ha deciso di partecipare con una diretta video, che non è ancora stata resa pubblica, ma è disponibile una trascrizione di domande e risposte riprodotta alla fine di questo articolo e scaricabile anche in formato PDF tramite il link nell’IFRAME di Scribd.

La lettura del testo è molto interessante: non contiene nulla di nuovo, ma fa il punto sulla posizione di Snowden e sulle sue motivazioni.

Dal punto di vista tecnico questo passaggio è degno di nota:

The good news is that there are solutions. The weakness of mass surveillance is that it can very easily be made much more expensive through changes in technical standards: pervasive, end-to-end encryption can quickly make indiscriminate surveillance impossible on a costeffective basis. The result is that governments are likely to fall back to traditional, targeted surveillance founded upon an individualized suspicion. Governments cannot risk the discovery of their exploits by simply throwing attacks at every “endpoint,” or computer processor on the end of a network connection, in the world. Mass surveillance, passive surveillance, relies upon unencrypted or weakly encrypted communications at the global network level.

Come molti esperti del settore ripetono da tempo, la cifratura dei dati è utile; per citare un esempio, si veda il discorso di Mikko Hyppönen sulla NSA. Leggi tutto “Testimonianza di Snowden al Parlamento Europeo”

Perfect Forward Secrecy

Il protocollo HTTPS come è implementato da molti siti o browser ha un problema con il futuro.

Ipotizzando che qualcuno stia registrando tutto il traffico HTTPS di un sito adesso potrebbe solamente avere in mano dei dati illeggibili. Ma cosa succederebbe se venisse trafugata la chiave segreta, oppure se un domani i computer riuscissero in poche settimane a scardinare la chiave utilizzata?

C’è un passaggio fondamentale nei primi millisecondi del protocollo HTTPS:

Il browser, verificato il certificato, invia un messaggio al server che contiene un altro numero casuale cifrato con la chiave pubblica del server

Quindi, chi riuscisse a calcolare o trafugare la chiave privata del server potrebbe decifrare tutto il traffico HTTPS protetto con quella coppia di chiavi, ipoteticamente salvato negli anni, che fino a quel momento non era decifrabile (retrospective decryption).

Lo scambio di una chiave segreta condivisa su un canale non sicuro è un problema non nuovo. Whitfield DiffieMartin Hellman e Ralph Merkle avevano trovato una soluzione già negli anni ’70 del secolo scorso elaborando quello che poi sarebbe diventato il protocollo Diffie-Hellman per lo scambio di chiavi (brevetto US4200770 ora scaduto).

Anche in questo caso bisogna fare un passo indietro per vedere come funzionano le cose dietro le quinte.

Leggi tutto “Perfect Forward Secrecy”