Application Security: internet, mobile ed oltre · 2017-01-23 · Applicazione . Trasporto (TCP) Rete (IP) Data Link : Fisico . WPA2 . IPsec . SSL/TLS SSH PGP . S-HTTP •Tali protocolli

3.10.2014 - Venezia - ISACA VENICE Chapter 1

SSL, se non ci fosse bisognerebbe (re)inventarlo - G. SALVALAGGIO

Application Security: internet, mobile ed oltre

SSL, se non ci fosse bisognerebbe (re)inventarlo

Gianluca Salvalaggio

Venezia, 3 ottobre 2014



SSL, se non ci fosse bisognerebbe

(re)inventarlo

v. 1.2



Application Security: internet, mobile ed oltre

Sponsor e sostenitori di ISACA VENICE Chapter

Con il patrocinio di

Organizzatori



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)



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.



Agenda

• Introduzione •Crittografia (molto) brevemente •Evoluzione del protocollo SSL/TLS •Protocollo SSL •Attacchi •Considerazioni



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.



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



Introduzione

• I vari protocolli di sicurezza operano a differenti livelli dello stack TCP/IP.

Applicazione

Trasporto (TCP)

Rete (IP)

Data Link

Fisico

WPA2

IPsec

SSL/TLS SSH

PGP S-HTTP

• Tali protocolli sono più o meno complessi a seconda del livello in cui agiscono, ma il loro obiettivo è comune: proteggere i dati trasmessi.



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



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)

testo in chiaro (P) testo in chiaro (P)

testo cifrato (C)

cLq+p£xfjhr*wk àFt%okp8d$ew La vita è uguale a una

scatola di cioccolatini, non sai mai quello che ti capita!

La vita è uguale a una scatola di cioccolatini, non sai mai quello che ti capita!

Alice Bob

Decifratura Cifratura

Eva

C = E(P), P = D(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 (Kpub) e quest’ultimo usa la propria chiave Privata (Kpri) 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.

• 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 = EK(P), P = DK(C)




Simmetrici

Cifratura Decifratura

Bob

testo in chiaro testo in chiaro

testo cifrato

Andai nei boschi perché volevo vivere con saggezza e …

cKç+p£xfher*wk#àot%U3_e$ …

K K

Andai nei boschi perché volevo vivere con saggezza e …

Asimmetrici

Alice

Kpri

Cifratura Decifratura

Bob

testo in chiaro testo in chiaro testo cifrato

Si dirada la nebbia, molli gli ormeggi, ti

stacchi e percorri … iLt5y£xfter*wa# àPt%j3xd$Kx…

Si dirada la nebbia, molli gli ormeggi, ti

stacchi e percorri …

Alice Kpub

Kpub




Simmetrica

• Pro: algoritmi veloci, lunghezza delle chiavi = 128 256 bit

• Contro: distribuzione delle chiavi: N utenti chiavi

• Gli algoritmi simmetrici si dividono in:

a blocco (block ciphers): 3DES, AES, …

a flusso (stream ciphers): RC4

Asimmetrica

• 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

2)1( −NN

Simmetrica vs Asimmetrica




«Il giusto sta nel mezzo: schema ibrido»

Kpri

Cifratura simmetrica

Bob

testo in chiaro testo in chiaro

testo cifrato

ipt5y£xfter*wa# à{t%U3erfmn7aerPua4&fxd$ …

Alice

Kpub

Kpub

Decifratura simmetrica

Cifratura asimmetrica

Nel mezzo di cammin di

nostra vita … Nel mezzo di

cammin di nostra vita …

Xd$y4k#qz&W

chiave K cifrata

K K Decifratura asimmetrica

• Alice genera una chiave di sessione (simmetrica) K e la cifra con la chiave pubblica di Bob Kpub ; poi cifra il messaggio con K e spedisce tutto a Bob.

• Bob usa la propria chiave privata Kpri per ottenere la chiave di sessione K e con questa decifra il messaggio.

Lo schema ibrido, adottato dai vari protocolli, coniuga i pregi delle due tecniche:



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.



Evoluzione del protocollo SSL

• 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).

• Abbiamo detto che negli anni ’90 vennero sviluppati protocolli di sicurezza nei vari livelli dello stack TCP/IP.

[1] http://tools.ietf.org/html/rfc2660

• 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

Trasporto (TCP)

Rete (IP)

Data Link

Fisico

SSL

S-HTTP



Evoluzione del protocollo SSL

• 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).

• 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.

[1] http://tools.ietf.org/html/draft-hickman-netscape-ssl-00

[2] http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00

• 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

• 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)



Protocollo SSL

• Nel corso degli anni il protocollo SSL/TLS è stato migliorato e irrobustito, ma l’idea di base è rimasta la stessa.

} SSL Protocol

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.



Protocollo SSL

• Il Record Protocol incapsula i messaggi SSL e fornisce servizi di confidenzialità e integrità.

Signorina, veniamo noi con questa mia addirvi una parola che, scusate se sono poche …

Signorina, veniamo noi con questa mia addirvi una parola che, scusate se sono poche …

MAC

Application data

frammentazione

compressione

aggiunta del MAC

cifratura

aggiunta header

Il Record Protocol è responsabile del trasferimento vero e proprio: provvede alla frammentazione, compressione, segnatura (MAC), padding e cifratura dei dati.



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



Protocollo SSL

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.

Handshake Protocol



Protocollo SSL

Dopo la 3 fase di handshake, client e server condividono il pre_master_secret, con il quale generano il master_secret (48

Calcolo del master_secret

Calcolo delle chiavi

I II III IV V VI

Key exchange

pre_master_secret

master_secret

ClientRandom ServerRandom

I. Client write MAC key II. Server MAC key III. Client cipher key IV. Server cipher key V. Client IV VI. Server IV

byte). A partire da quest’ultimo vengono calcolate tutte le chiavi crittografiche.



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)

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

Esempi di CipherSuite:



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

http://nerdoholic.org/uploads/dergln/beast_part2/ssl_jun21.pdf



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.

[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

• È 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.




B.E.A.S.T. Schema CBC

Cifratura

Decifratura

NOTA: rappresenta l’operatore binario XOR (Proprietà: m m = 0; m 0 = m)

===================================================================================================================

Ci = EK(Ci-1 Pi)

Pi = DK(Ci) Ci-1

C0 ≡ IV



B.E.A.S.T.

Pi-1

EK()

Pi = cookie Pi+1

Ci-1

K EK()

Ci

K EK()

Ci+1

K

Eva sa che il blocco Pi contiene il cookie di sessione: per lei è un valore incognito X ma sa che viene cifrato nel blocco Ci = EK(Pi Ci-1). Ricordiamo che Eva può intercettare tutti i blocchi di ciphertext (Ci-1, Ci ,..)

Pj-1

EK()

Pj = G Pj+1

Cj-1

K EK()

Cj

K EK()

Cj+1

K

Eva prova a verificare se G è il valore corretto di cookie. Induce Alice a spedire il blocco Pj=G Ci-1 Cj-1 . Da cui: Cj = EK(G Ci-1 Cj-1 Cj-1 ) = = EK(G Ci-1) Se Cj = Ci allora G è proprio il valore del cookie: G=X



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 (28)8 = 264 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:

Session= A1F451m9 Invio normale:

Eva altera la richiesta HTTP in modo da avere: ession=A 1F451m9

Pi Pi+1 In questo modo Pi ha solo un carattere 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:

Eva al più dovrebbe fare 264 tentativi Pi

ssion=A1 F451m9

Pi Pi+1 Con altri 256 tentativi Eva scopre anche il carattere ‘1’. In questo modo, con soli 8*256 = 211 tentativi, Eva potrà scoprire il valore del cookie.



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.



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].

[1] http://www.iacr.org/cryptodb/archive/2002/FSE/3091/3091.pdf

• 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.

• 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.




C.R.I.M.E.

1. L’attaccante induce la vittima ad accedere ad un sito da lui controllato.

2. La vittima accede al sito dal quale riceve il codice maligno che verrà eseguito sul suo browser.

3. La vittima accede al sito protetto (Server), ottenendo un valido cookie di sessione.

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.

Server



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.

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 ………….>

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.



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).

[1] https://www.trustworthyinternet.org/ssl-pulse/

• 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.




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




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;

struct ssl3_record_st { unsigned int length; /*how many bytes*/ uchar *data; /*pointer to data*/ [...] } SSL3_RECORD;

Struttura di un messaggio Heartbeat.

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.



Heartbleed

Analizziamo il codice[1] che elabora il messaggio di Heartbeat in arrivo e che prepara il messaggio di risposta..

Ricezione del messaggio nella variabile payload viene salvato il contenuto del campo payload_length del messaggio di Heartbeat (HB). p1 punta ai dati spediti nel messaggio HB.

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, …

/* Read type and payload length first */ hbtype = *p++; n2s(p, payload); pl = p;

/* 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




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




Heartbleed

Il bug è stato risolto nella versione 1.0.1g di OpenSSL, introducendo un semplice boundary check.

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).

/* 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;

• 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.



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.



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

• TLS è oggetto continuo di studio, e dai vari attacchi «impara la lezione» e si migliora ….

[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

se non ci fosse …….

Considerazioni

Fonte: [2]






Domande …



Grazie per l’attenzione!

Gianluca Salvalaggio > http://www.linkedin.com/in/salvalaggio > [email protected]

Documents

Application Security: internet, mobile ed oltre · 2017-01-23 · Applicazione . Trasporto (TCP) Rete (IP) Data Link : Fisico . WPA2 . IPsec . SSL/TLS SSH PGP . S-HTTP •Tali protocolli