HeartBleed - Perchè così pericoloso ?

[LoryOne]

Beh ragazzi, facciamo un po di luce su questa falla così pericolosa, che ne dite ?
Prima di tutto, cerchiamo di capire in cosa consiste la paura del bug e perchè sia necessario che si proceda ad aggiornare il toolkit per TLS/SSL sui server interessati, il prima possibile.
La paura è fondata, poichè nessuno fino a poco tempo fa si era mai accorto di un errore d'implementazione di OpenSSL che potesse rivelare più di quanto ci si aspettasse: Il dumping della memoria.
Alcuni di voi (forse nessuno, forse qualcuno) avrà sicuramente sentito parlare di SSLStrip.
Ebbene, SSLStrip da solo non fa proprio nulla: Affinchè funzioni, esso deve essere utilizzato in combinazione con iptables e con direttiva PREROUTING, affinchè si possa bypassare il layer su socket sicuro (SSL).
Un layer, non è forse uno strato e più layers non formano più strati sovrapposti (The Onion Router) ?
La risposta è affermativa, anzi, aggiungo che cifratura e decifratura delle informazioni sotto SSL avvengono in locale ed in memoria locale; La memoria è locale sia sul server, sia sul client, indipendentemente dal numero di layers che si frappongono tra il client ed il server, sebbene comunichino tra loro secondo cifratura, attraverso internet.
Non è certo SSLStrip il fulcro della questione, tantomeno è mia intenzione parlarne approfonditamente, ma tra poco vi renderte conto del perchè l'ho citato "di sfuggita" a proposito di bypass.
Andiamo con ordine e focalizziamoci sulla ricerca di informazioni riguardo al cuore sanguinolento che siano sufficientemente esaustive per avere almeno un punto di partenza:
http://blog.trendmicro.com/trendlabs...vulnerability/

Leggiamo:
"The vulnerability, dubbed as the Heartbleed Bug, exists on all OpenSSL implementations that use the Heartbeat extension"

Cos'è questa Heartbeat extension ?
Chi ha dimestichezza con openssl, saprà sicuramente come verificare l'estensione di cui si parla e saprà sicuramente che openssl è in grado di fornire informazioni dettagliate del processo di handshake per stabilire una connessione sicura via TLS/SSL, seppur per scopi di debug:

openssl s_client -connect server.com:443 -tlsextdebug
oppure (Ricerca con grep e visualizza la stringa "heartbeat" nello stream generato da openssl, interpretato da echo, ritornando al prompt quando incontra a capo)
echo -e "quit\n" | openssl s_client -connect server.com:443 -tlsextdebug 2>&1 | grep heartbeat

Ricercando in internet, troverà che Heartbeat affligge OpenSSL in diverse sue versioni di rilascio, diciamo antiquate, rispetto all'odierno 2014.
Vi sarà chiaro che la prima operazione da effettuare per chi volesse sfruttare il baco, sarebbe quella di testare ogni singolo sito che ospitasse OpenSSL e fosse corredato dall'estensione indicativa della vulnerabilità presa in esame.

Leggiamo ancora:
"When exploited on a vulnerable server, it can allow an attacker to read a portion — up to 64 KB’s worth — of the computer’s memory at a time, without leaving any traces"

Chiaro.
Stiamo interrogando un server senza reale scambio dati, solo connettendoci attraverso handshake.
Interessanti i 64 kb, non trovate ?

Leggiamo ancora:
"This small chunk of memory could contain user-critical personal information — private keys, usernames, passwords (in cleartext in a lot of cases), credit card information, and confidential documents for example. The attacker could request this chunk again and again in order to get as much information as they want – and this bug could be exploited by anyone on the Internet, anywhere."

Perbacco ! chiavi private, nomi utente, password in chiaro (in molti casi), informazioni su carte di credito, documenti confidenziali.
Come è possibile ricavare tutte queste informazioni da un protocollo protetto da cifratura !?!
La risposta risiede nel fatto che TLS/SSL è un ulteriore strato del livello più alto (Application) della pila OSI del protocollo TCP/IP e se questo è mal implementato e funziona su un server, nei pacchetti di ritorno può confluire parte della memoria di quel server...
Più interrogazioni vengono eseguite, maggiore è la possibilità che tra le informazioni ricevute ci siano quelle di maggiore interesse, non per ultimi i certificati utili ad attacchi di falsa impersonificazione, redirect, packet injection, man in the middle...
Ahimè, Il cuore sanguina.

Buona serata a tutti.

ps: Prima di mettere mano ai vs. account, cambiando password e dati personali, premuratevi di verificare che quel sito non sia più vulnerabile, perchè in caso contrario, perdereste tempo inutilmente.
Cordialità

[axell]

Inviato da LoryOne

ps: Prima di mettere mano ai vs. account, cambiando password e dati personali, premuratevi di verificare che quel sito non sia più vulnerabile, perchè in caso contrario, perdereste tempo inutilmente.
Cordialità

e come si effettua questa verifica?

[RunDLL]

Almeno per una volta quello sotto accusa è Linux.

[booty island]

Non é Linux direttamente ma di OpenSSL: quest'ultimo è disponibile anche per Windows, ad esempio.

[RunDLL]

Mi risulta nello specifico che il problema affligge esclusivamente i mail server con Debian e derivati.

[booty island]

Tutti i sistemi con OpenSSL non aggiornati sono a rischio, mentre con la versione 1.0.1g si chiude la falla.