Application Security: internet, mobile ed oltre SSL, se non ci fosse bisognerebbe (re)inventarlo Gianluca Salvalaggio Venezia, 3 ottobre 2014 1
SSL, se non ci fosse bisognerebbe (re)inventarlo v. 1.2 2
Application Security: internet, mobile ed oltre Organizzatori Sponsor e sostenitori di ISACA VENICE Chapter Con il patrocinio di 3
Gianluca Salvalaggio Responsabile della Sicurezza Informatica del Gruppo Bassilichi S.p.A CISSP. Laureato in Ingegneria e in Informatica. > 10+ anni nel campo dell'information Security > docente in corsi di Networking e Sicurezza Informatica (e Astronomia) 4
ABSTRACT Il protocollo SSL/TLS garantisce la sicurezza e la privacy delle principali comunicazioni su Internet: siti di e-commerce, servizi di webmail, home banking, etc etc. Dopo una breve descrizione dei principi di funzionamento, vengono presentati gli attacchi che in questi ultimi anni hanno sfruttato vulnerabilità architetturali o implementative del protocollo. 5
Agenda Introduzione Crittografia (molto) brevemente Evoluzione del protocollo SSL/TLS Protocollo SSL Attacchi Considerazioni 6
Introduzione C era una volta... Internet nacque negli anni 80 da uno scorporo dell esistente rete, di emanazione militare, ARPANET. Nata per scopi di ricerca scientifica, agli inizi Internet utilizzava protocolli che oggi consideriamo un po vintage: TELNET, FTP, POP, SMTP, NNTP. Si tratta di protocolli relativamente semplici, accumunati da una stessa caratteristica: trasferiscono i dati IN CHIARO, senza alcuna protezione. D altra parte negli anni 80 la sicurezza delle trasmissioni non era sentita come esigenza, tantomeno come priorità. Internet veniva utilizzata quasi esclusivamente da Università e istituti di ricerca. 7
Introduzione Negli anni 90 le cose cambiarono radicalmente: nacque il World Wide Web (1989) arrivarono i primi servizi di e-commerce (1994, Amazon) arrivarono i primi servizi di Internet Banking (1995) Internet ampliò enormemente il proprio bacino di utenza e soprattutto cominciò a veicolare $OLDI. La sicurezza delle trasmissioni divenne una necessità. Vennero proposti protocolli e meccanismi di sicurezza, tuttora largamente utilizzati. PGP (1991) Pretty Good Privacy SSL (1994) Secure Socket Layer SSH (1996) Secure Shell IPsec (1998) IP security S-HTTP (1999) Secure HTTP 8
Introduzione I vari protocolli di sicurezza operano a differenti livelli dello stack TCP/IP. Applicazione Trasporto (TCP) SSH PGP SSL/TLS S-HTTP Rete (IP) IPsec Data Link WPA2 Fisico Tali protocolli sono più o meno complessi a seconda del livello in cui agiscono, ma il loro obiettivo è comune: proteggere i dati trasmessi. 9
Introduzione Ma cosa significa proteggere (mettere in sicurezza) i dati? L RFC 2828 (Internet Security Glossary) ci viene in aiuto con alcune definizioni security service: a processing or communication service that is provided by a system to give a specific kind of protection to system resources. Esempi: data confidentiality data integrity data origin authentication security mechanism: a process (or a device incorporating such a process) that can be used in a system to implement a security service. Esempi: encryption hash function digital signature 10
Crittografia (molto) brevemente Crittografia: il messaggio viene alterato utilizzando un procedimento concordato da mittente e destinatario in modo che risulti incomprensibile ad un eventuale avversario che riesca ad intercettarlo. Cifratura E(): il messaggio in chiaro (P, plaintext) viene modificato, ottenendo il testo cifrato (C, ciphertext) Decifratura D(): dal testo cifrato (C) viene ricostruito il messaggio in chiaro (P) C = E(P), P = D(C) Alice La vita è uguale a una scatola di cioccolatini, non sai mai quello che ti capita! Cifratura testo cifrato (C) clq+p xfjhr*wk àft%okp8d$ew Decifratura Bob La vita è uguale a una scatola di cioccolatini, non sai mai quello che ti capita! testo in chiaro (P) testo in chiaro (P) Eva 11
Crittografia (molto) brevemente Mittente e destinatario condividono una conoscenza segreta che consente la cifratura del messaggio e la corrispondente decifratura. Tale conoscenza NON è il processo di alterazione ma la chiave K: un valore/stringa che parametrizza la funzione di cifratura e di decifratura. C = E K (P), P = D K (C) A seconda dei valore delle chiavi, gli algoritmi di cifratura si dividono in: simmetrici: i processi di cifratura e di decifratura usano la stessa chiave K asimmetrici: la chiave usata dal processo di cifratura è diversa da quella utilizzata nel processo di decifratura. Più precisamente, il mittente cifra il messaggio con la chiave Pubblica del destinatario (K pub ) e quest ultimo usa la propria chiave Privata (K pri ) per decifrare il testo ricevuto. La chiave pubblica NON consente la decifratura. Il legame che unisce le due chiavi (Pubblica e Privata) è di natura matematica. 12
Crittografia (molto) brevemente Simmetrici Alice K K Bob Andai nei boschi perché volevo vivere con saggezza e testo in chiaro Cifratura ckç+p xfher*wk #àot%u3_e$ Decifratura Andai nei boschi perché volevo vivere con saggezza e testo in chiaro testo cifrato Asimmetrici Bob K pub Alice K pub K pri Si dirada la nebbia, molli gli ormeggi, ti stacchi e percorri testo in chiaro Cifratura ilt5y xfter*wa# àpt%j3xd$kx testo cifrato Decifratura Si dirada la nebbia, molli gli ormeggi, ti stacchi e percorri testo in chiaro 13
Crittografia (molto) brevemente Simmetrica vs Asimmetrica Simmetrica Pro: algoritmi veloci, lunghezza delle chiavi = 128 256 bit Contro: distribuzione delle chiavi: N utenti Gli algoritmi simmetrici si dividono in: a blocco (block ciphers): 3DES, AES, a flusso (stream ciphers): RC4 Asimmetrica N( N 1) 2 chiavi Pro: risolve il Problema della Distribuzione delle Chiavi Contro: algoritmi lenti, lunghezza delle chiavi = 2048 bit Si basa su problemi matematici difficili da risolvere (IFP, DLP, ECDLP) Algoritmi principali: RSA, El Gamal, Diffie-Hellman (*), ECC 14
Crittografia (molto) brevemente «Il giusto sta nel mezzo: schema ibrido» Lo schema ibrido, adottato dai vari protocolli, coniuga i pregi delle due tecniche: Alice genera una chiave di sessione (simmetrica) K e la cifra con la chiave pubblica di Bob K pub ; poi cifra il messaggio con K e spedisce tutto a Bob. Bob usa la propria chiave privata K pri per ottenere la chiave di sessione K e con questa decifra il messaggio. K pub K pub K pri Bob Alice K Cifratura asimmetrica Xd$y4k#qz&W Decifratura asimmetrica K Nel mezzo di cammin di nostra vita testo in chiaro Cifratura simmetrica chiave K cifrata ipt5y xfter*wa# à{t%u3erfmn7a erpua4&fxd$ Decifratura simmetrica Nel mezzo di cammin di nostra vita testo in chiaro testo cifrato 15
Crittografia (molto) brevemente MAC Il Message Authentication Code (MAC) utilizza una chiave condivisa fra mittente e destinatario e consente l autenticazione di un messaggio. Il MAC è una specie di digest crittografico che viene aggiunto al messaggio da spedire e permette al destinatario di verificare l autenticità del mittente e l integrità del messaggio. 16
Evoluzione del protocollo SSL Abbiamo detto che negli anni 90 vennero sviluppati protocolli di sicurezza nei vari livelli dello stack TCP/IP. Con l intento di proteggere le transazioni web direttamente a livello applicativo, l IETF propose il Secure HTTP (S-HTTP) [1]. Tale protocollo però non ebbe successo. Applicazione SSL Trasporto (TCP) Rete (IP) Data Link Fisico S-HTTP Nel 1994 la Netscape Communications sviluppò il protocollo Secure Socket Layer (SSL). La versione 1.0 però venne utilizzata solo internamente alla Netscape: non venne mai pubblicata. La scelta di Netscape fu di applicare la sicurezza a livello trasporto; più precisamente SSL si interpone fra il protocollo TCP e lo strato applicativo: i servizi di sicurezza NON sono legati ad una applicazione in particolare l applicazione beneficia di tali servizi di sicurezza in modo trasparente (senza modifiche) e consapevole (può decidere se usarli o meno). [1] http://tools.ietf.org/html/rfc2660 17
Evoluzione del protocollo SSL Agli inizi del 1995 Netscape pubblicò la versione 2.0 di SSL [1], che correggeva i difetti della 1.0 ed era supportata dal nuovo browser Netscape Navigator. Nel 1996 Netscape fece uscire la ver. 3.0 [2] di SSL che risolse alcune debolezze della versione precedente. Oggi l utilizzo della ver. 2.0 è deprecato In quegli anni Microsoft propose soluzioni molto simili all SSL: Private Communication Technology (PCT) e Secure Transport Layer Protocol (STLP). Al fine di standardizzare la situazione, l IETF, dopo una lunga gestazione, nel 1999 pubblicò lo standard TLS 1.0 (Transport Layer Security - RFC 2246). Nell aprile del 2006 venne rilasciata la ver. 1.1 di TLS (RFC 4346) Nel 2008 l IETF pubblicò la ver. 1.2 di TLS (RFC 5246) [1] http://tools.ietf.org/html/draft-hickman-netscape-ssl-00 [2] http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00 18
Protocollo SSL Nel corso degli anni il protocollo SSL/TLS è stato migliorato e irrobustito, ma l idea di base è rimasta la stessa. SSL/TLS garantisce: autenticazione, confidenzialità, integrità SSL/TLS agisce ad un livello intermedio fra il livello Trasporto (TCP) e il livello Applicativo. SSL/TLS è costituito da 2 layer e da 4 subprotocol nel layer inferiore il Record Protocol spedisce i messaggi SSL 4 tipi di messaggi SSL: Alert, ChangeChiperSpec, Handshake e Application data. } SSL Protocol 19
Protocollo SSL Il Record Protocol incapsula i messaggi SSL e fornisce servizi di confidenzialità e integrità. Application data Signorina, veniamo noi con questa mia addirvi una parola che, scusate se sono poche frammentazione Signorina, veniamo noi con questa mia addirvi una parola che, scusate se sono poche compressione aggiunta del MAC cifratura MAC Il Record Protocol è responsabile del trasferimento vero e proprio: provvede alla frammentazione, compressione, segnatura (MAC), padding e cifratura dei dati. aggiunta header 20
Protocollo SSL Il Change Cipher Spec Protocol consiste in un singolo messaggio (un byte valorizzato a 1 ) con il quale le impostazioni di sicurezza pendenti (pending state) vengono rese effettive (current state). L Alert Protocol segnala alle due entità comunicanti eventuali errori o malfunzionamenti, attraverso l invio di opportuni messaggi di allarme. L Handshake Protocol è il primo protocollo ad entrare in azione in quanto responsabile della negoziazione iniziale. E costituito da quattro fasi in sequenza: Inizializzazione: vengono stabiliti gli algoritmi crittografici Autenticazione del server e scambio chiavi Autenticazione del client e scambio chiavi Chiusura della negoziazione 21
Protocollo SSL Handshake Protocol 1. Con i due messaggi di hello, client e server concordano la CipherSuite, il session ID ed il metodo di compressione. Si inviano anche due numeri casuali (ClientRandom, ServerRandom). 2. Il server invia il proprio certificato (tranne quando si usa anonymous DH). Se necessario invia la chiave server_key_exchange. Opzionalmente richiede il certificato del client. 3. Se richiesto, il client invia il proprio certificato. Con il messaggio client_key_exchange invia il pre_master_secret (48 byte) cifrato con la chiave pubblica del server (ottenuta nella Fase 2)* 4. Il client invia il messaggio change_cipher_spec e copia il CipherSpec provvisorio in quello corrente. Il messaggio finished è cifrato con i parametri negoziati. Il server fa altrettanto. 22
Protocollo SSL Dopo la 3 fase di handshake, client e server condividono il pre_master_secret, con il quale generano il master_secret (48 byte). A partire da quest ultimo vengono calcolate tutte le chiavi crittografiche. Key exchange ClientRandom pre_master_secret ServerRandom I. Client write MAC key II. Server MAC key III. Client cipher key IV. Server cipher key V. Client IV VI. Server IV Calcolo del master_secret master_secret Calcolo delle chiavi I II III IV V VI 23
Protocollo SSL La CipherSuite, negoziata in fase di handshake, elenca i meccanismi crittografici da utilizzare nella sessione SSL: [Kx] algoritmo utilizzato per lo scambio chiavi (es: RSA, ephemeral DH) [Enc] algoritmo utilizzato per la cifratura (es: AES-128) [Mac] algoritmo hash usato per il calcolo del MAC (es: SHA-1) Esempi di CipherSuite: ECDHE-RSA-AES256-SHA Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES256-SHA Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 RC4-SHA Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 24
Attacchi al protocollo SSL In questi anni sono stati elaborati numerosi attacchi [1] al protocollo SSL/TLS. Tali attacchi hanno sfruttato vulnerabilità del protocollo riconducibili a: l architettura del protocollo debolezze degli algoritmi di cifratura (RSA, RC4) errori di implementazione Tra i vari attacchi citiamo: B.E.A.S.T. (architettura) C.R.I.M.E. (architettura) Heartbleed (implementazione) GOTO fail bug (implementazione) Lucky 13 (architettura) B.R.E.A.C.H. (architettura) Bleichenbacher on PKCS#1 (cifratura) RC4 biases (cifratura) Triple handshake (architettura) GnuTLS BoF vuln. (implementazione) [1] http://tools.ietf.org/html/draft-ietf-uta-tls-attacks-04 25
B.E.A.S.T. L attacco B.E.A.S.T (Browser Exploit Against SSL/TLS) [1] è stato presentato dai ricercatori Thai Doung e Juliano Rizzo, con una dimostrazione live, nel corso della conferenza Ekoparty del settembre 2011. È un attacco di tipo chosen plaintext (blockwise chosen boundary attack) che si ispira a studi effettuati in precedenza (2004 e 2006) da V. Bard [2]. Si applica quando SSL usa cifrari simmetrici a blocco (AES, 3DES) in modalità CBC (Cipher Block Chaining) e sfrutta la predicibilità dell IV [3]. E un attacco alla navigazione web (furto dei cookie di sessione) nel quale l attaccante (che chiameremo Eva) deve poter: sniffare il traffico HTTPS della vittima (es: in un Hotspot Wi-Fi) forzare la vittima a spedire richieste HTTP arbitrarie verso il server (usando codice maligno che bypassa la Same Origin Policy [SOP]) indurre la vittima (che chiameremo Alice) a scaricare il codice maligno (es: applet Java) da un sito sotto il suo controllo. [1] http://nerdoholic.org/uploads/dergln/beast_part2/ssl_jun21.pdf [2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61.5887&rep=rep1&type=pdf [3] l IV (initialization vector) è un numero casuale che innesca la cifratura aggiungendo entropia al processo 26
B.E.A.S.T. Schema CBC Cifratura C i = E K (C i-1 P i ) C 0 IV =================================================================================================================== Decifratura P i = D K (C i ) C i-1 NOTA: rappresenta l operatore binario XOR (Proprietà: m m = 0; m 0 = m) 27
B.E.A.S.T. P i-1 P i = cookie P i+1 K E K () K E K () K E K () C i-1 C i C i+1 Eva sa che il blocco P i contiene il cookie di sessione: per lei è un valore incognito X ma sa che viene cifrato nel blocco C i = E K (P i C i-1 ). Ricordiamo che Eva può intercettare tutti i blocchi di ciphertext (C i-1, C i,..) P j-1 P j = G P j+1 K E K () K E K () K E K () C j-1 C j C j+1 Eva prova a verificare se G è il valore corretto di cookie. Induce Alice a spedire il blocco P j =G C i-1 C j-1. Da cui: C j = E K (G C i-1 C j-1 C j-1 ) = = E K (G C i-1 ) Se C j = C i allora G è proprio il valore del cookie: G=X 28
B.E.A.S.T. Andando per tentativi di G (guess) Eva riuscirà a indovinare il valore di cookie X. Se però i blocchi P sono da 8 caratteri, X potrà assumere (2 8 ) 8 = 2 64 valori ed Eva dovrà fare altrettanti tentativi!!! L approccio di Doung e Rizzo consiste nel provare ad indovinare un carattere alla volta, traslando il valore di cookie attraverso i blocchi P. In questo modo si riduce drasticamente il n di tentativi che Eva dovrà fare: Invio normale: Session= A1F451m9 Eva altera la richiesta HTTP P i P i+1 In questo modo P i ha solo un carattere in modo da avere: ession=a 1F451m9 incognito (il 1 carattere del cookie). Eva dovrà fare solo 256 tentativi per scoprire il valore A. Scoperto il carattere A Eva induce Alice ad inviare una nuova richiesta in modo da avere: P i Eva al più dovrebbe fare 2 64 tentativi P i P i+1 Con altri 256 tentativi Eva scopre anche il F451m9 carattere 1. In questo modo, con soli 8*256 = 2 11 tentativi, Eva potrà scoprire il valore del cookie. ssion=a1 29
B.E.A.S.T. B.E.A.S.T. funziona con SSL 3.0 e TLS 1.0; a partire dalla versione 1.1 di TLS, infatti, è stato introdotto l IV esplicito che rende inefficace tale attacco. Con l IV esplicito ogni blocco viene cifrato con un suo IV casuale. Contromisure dopo la pubblicazione dell attacco si era suggerito, come mitigazione server-side, di abilitare solo Ie Cipher suite con RC4 (escludendo i cifrari a blocco 3DES e AES). Le debolezze di RC4 scoperte di recente suggeriscono di NON usare più tale algoritmo. La raccomandazione è di usare TLS 1.1 e 1.2. mantenere browser e plugin sempre aggiornati (per evitare il SOP bypass). all interno di reti insicure (es: hotspot) navigare in modo accorto; ad esempio non accedere contemporanemente a siti sensibili (con autenticazione) e ad altri siti. 30
C.R.I.M.E. L attacco C.R.I.M.E. (Compression Ratio Info-leak Made Easy) è stato presentato dai ricercatori Thai Doung e Juliano Rizzo in occasione della conferenza Ekoparty 2012 (un déja vu). È un esempio di side-channel attack che, in particolare, rivela informazioni sul plaintext sfruttando la compressione di SSL. Questo tipo di vulnerabilità è stata scoperta nel 2002 [1]. L attaccante può manipolare i dati inviati dalla vittima e osservando la riduzione delle dimensioni del ciphertext, dovuta a ridondanze eliminate dalla compressione, l attaccante riesce ad ottenere il valore del cookie. L attaccante deve poter: sniffare il traffico HTTPS della vittima forzare la vittima a spedire richieste HTTP arbitrarie verso il server indurre la vittima (che chiameremo Alice) a scaricare il codice maligno (Javascript) da un sito sotto il suo controllo. [1] http://www.iacr.org/cryptodb/archive/2002/fse/3091/3091.pdf 31
C.R.I.M.E. 2. La vittima accede al sito dal quale riceve il codice maligno che verrà eseguito sul suo browser. Server 3. La vittima accede al sito protetto (Server), ottenendo un valido cookie di sessione. 1. L attaccante induce la vittima ad accedere ad un sito da lui controllato. 4. L attaccante può sniffare il traffico (cifrato) fra la vittima ed il Server. Attraverso il codice iniettato, induce la vittima a spedire pacchetti opportunamente «forgiati» per ricavare il cookie. 32
C.R.I.M.E. Una volta che il codice maligno va in esecuzione nel browser della vittima, l attaccante comincia ad indovinare (guess) il valore del cookie, forzando la vittima a spedire il guess insieme al reale valore del cookie. Se osserva una riduzione nella dimensione del ciphertext significa che il guess ha introdotto ridondanza nel plaintext. A destra riportiamo una tipica richiesta al Server protetto. L attaccante non può vederla (è in HTTPS) ma sa che contiene la stringa «session=?????????»: vuole capire cosa mettere al posto dei «?». L attaccante fa spedire alla vittima richieste contenenti un guess sempre diverso, del tipo session=x (dove X è un carattere qualsiasi). La sola richiesta con guess pari a session=9 otterrà una compressione maggiore e quindi avrà dimensione minore. POST / HTTP/1.1 Host: gianluca.xyz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Cookie: session=9rnybj4wpnm7 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 <. request body.> POST /session=0 HTTP/1.1 Host: gianluca.xyz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Cookie: session=9 rnybj4wpnm7 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 <. request body.> 33
C.R.I.M.E. Una volta indovinato il primo carattere del cookie (in questo caso 9) ripeterà il processo per tutti gli altri caratteri (con guess uguali a session=9x e così via). Contromisure L attacco sfrutta la compressione SSL e questa va disabilita sia lato server che lato client. Lato server. Secondo SSLPulse [1] (aggiornato al 4 settembre 2014) il 9,1% dei server monitorati ha ancora abilitata la compressione SSL. Lato client. La bella notizia è che ormai in tutti i browser la compressione SSL è disabilitata (nel ClientHello che inviano il metodo di compressione è null). B.R.E.A.C.H. (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext), presentato nel 2013, è un altro attacco di tipo side-channel che sfrutta la compressione non di SSL/TLS ma del protocollo HTTP e analizza le dimensioni delle risposte HTTP. [1] https://www.trustworthyinternet.org/ssl-pulse/ 34
Heartbleed Una vulnerabilità legata a TLS che ha fatto molto parlare di sé è Heartbleed. Scoperta ad aprile 2014, in realtà non si tratta di una vulnerabilità del protocollo, ma piuttosto è un grave bug della libreria OpenSSL, forse la più diffusa implementazione di SSL/TLS [1]. E un bug di tipo buffer over-read relativo al meccanismo TLS Heartbeat extension (RFC 6520). Tale estensione del protocollo utilizza messaggi di keep-alive (tipo echo) con i quali le due entità constatano di essere ancora connesse: una delle due spedisce un messaggio Heartbeat contenente un payload arbitrario (max 16 KiB), l altra risponde con un altro messaggio contenente lo stesso payload (a conferma che la connettività è OK). Di per sé il meccanismo di Heartbeat non sembra così pericoloso, ma come sappiamo «il diavolo si nasconde nei dettagli»: la prima entità può fare spedire alla seconda molti più dati di quanti gliene ha inviati (fino a 64 KiB). [1] https://www.openssl.org/news/secadv_20140407.txt 35
Heartbleed Per capire come funziona questo attacco bisogna osservare il codice C della libreria. struct { HeartbeatMessageType type; /*1 byte */ uint16 payload_length; opaque payload[heartbeatmessage.payload_length]; opaque padding[padding_length] } HeartbeatMessage; Struttura di un messaggio Heartbeat. struct ssl3_record_st { unsigned int length; /*how many bytes*/ uchar *data; /*pointer to data*/ [...] } SSL3_RECORD; Struttura di un Record SSL che, ricordiamo, è alla base di tutti i messaggi SSL. Il campo length è di 2 byte quindi la lunghezza massima è di 64 KiB. 36
Heartbleed Analizziamo il codice [1] che elabora il messaggio di Heartbeat in arrivo e che prepara il messaggio di risposta.. Ricezione del messaggio /* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p; nella variabile payload viene salvato il contenuto del campo payload_length del messaggio di Heartbeat (HB). p1 punta ai dati spediti nel messaggio HB. /* Allocate memory for the response,size is 1 bytes * message type, plus 2 bytes payload length, plus * payload, plus padding */ buffer = OPENSSL_malloc(1 + 2 + payload + padding); bp = buffer; /* Enter response type, length and copy payload */ *bp++ = TLS_HB_RESPONSE; S2n(payload, bp); memcpy(bp, p1, payload); r = ssl3_write_bytes(s, TLS_RT_HEARTBEAT, buffer, 3 + payload + padding); [1] ssl/t1_lib.c Creazione del messaggio di risposta viene allocato uno spazio di memoria grande payload bytes. Il problema è che ci fidiamo di questo valore senza fare alcun boundary check!!!! Il danno arriva con la memcpy(): copio nel buffer payload bytes dalla mia memoria, a prescindere da quanti bytes erano contenuti nel messaggio di HB. I dati copiati in eccesso potranno contenere password, chiavi, 37
Heartbleed Sfruttando questo bug l attaccante spedisce un messaggio di Heartbeat con solo 1 byte di dato (es: a ) ma specificando come payload_legth il max consentito dal Record SSL : 64 KiB. In questo modo il Server vittima risponderà pescando dalla propria memoria, per un totale di 64 KiB. Fonte: Wikipedia 38
Heartbleed Il bug è stato risolto nella versione 1.0.1g di OpenSSL, introducendo un semplice boundary check. /* Read type and payload length first */ if (1 + 2 + 16 > s->s3->rrec.length) return 0; /* silently discard */ hbtype = *p++; n2s(p, payload); if (1 + 2 + payload + 16 > s->s3->rrec.length) return 0; /* silently discard per RFC 6520 */ pl = p; Ricezione del messaggio (fixed) Il primo check scarta i messaggi HB di tipo zero-length (senza dati). Il secondo, e decisivo, check verifica che la variabile payload sia veritiera e che corrisponda all effettiva lunghezza del messaggio HB ricevuto (s->s3->rrec.lenth è la lunghezza effettiva del Record che ha trasportato il messaggio HB ricevuto). Ricordiamo comunque che Heartbleed NON è una vulnerabilità del protocollo SSL/TLS ma è un bug di OpenSSL (nelle ver. 1.0.1 1.0.1f) relativo ad una scorretta gestione dei messaggi di Heartbeat. 39
Considerazioni Il protocollo SSL/TLS compie 20 anni e dopo qualche iniziale difetto di gioventù ha raggiunto un buon livello di maturità. Uno dei motivi del suo successo è legato alla scelta di Netscape di posizionarlo al livello giusto: nè troppo in basso, nè troppo in alto. Protegge in modo trasversale alle applicazioni (cfr. S-HTTPS) ma senza isolarle troppo dai meccanismi di sicurezza (cfr. IPSec). Oggi è il protocollo di sicurezza più utilizzato e sta diventando «un default» per le comunicazioni in Internet (e non solo): da agosto 2014 i siti in HTTPS ottengono un maggior ranking nelle ricerche di Google. quasi tutti i browser (IE a partire dalla versione 12) supportano il meccanismo HSTS (HTTP Strict Transport Security). Il 19 agosto 2014 Facebook ha comunicato che il 95% delle mail di notifica vengono spedite in modo cifrato (SMTP with STARTTLS). Il caso NSAgate ha spinto tutti verso una pervasiva cifratura delle comunicazioni. 40
Considerazioni Molte delle minacce al protocollo TLS sono dovute a: scarsa adozione del più sicuro TLS 1.2 agosto 2014: WinXP è ancora al 24% errori di implementazione nelle librerie errori di implementazione nelle applicazioni 68% delle top 1.000 Android apps hanno vulnerabilità SSL [2]. errate configurazioni [1] utilizzo di cipher suite deboli (RC4, DES, ) supporto a SSLv2 o SSLv3 SSLPulse- settembre 2014 Fonte: [2] TLS è oggetto continuo di studio, e dai vari attacchi «impara la lezione» e si migliora. se non ci fosse. [1] https://www.ssllabs.com/projects/best-practices/ [2] http://www.fireeye.com/blog/technical/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html 41
Domande 42
Grazie per l attenzione! Gianluca Salvalaggio > http://www.linkedin.com/in/salvalaggio > gianluca.salvalaggio@constriv.it 43