Heartbleed: anche AlterVista ne è/era affetta?

[tecnomente]

Salve,
da qualche giorno si parla tanto dello "scandalo" Heartbleed che ha colpito la maggioranza dei siti utilizzanti il protocollo HTTPS.
Vorrei sapere se anche AV è stata colpita da questa falla e se i pannelli di amministrazione (sia di AV che dei vari CMS) erano sicuri.
Ringrazio tutti anticipatamente per le risposte :-)

[OT] Ma AlterVista va al maschile o al femminile? :D [/OT]

[EcologicoFaiDaTe]

Da questo elenco sembra che AlterVista sia salva :-)
https://github.com/musalbas/heartble...er/top1000.txt

Alla riga 641.

[alemoppo]

Lì dice che av non lo usa, anche se in realtà penso sia usato almeno per login e phpmyadmin. Quindi magari non hanno guardato "bene".
In ogni caso non ho capito perché c'é tutto questo allarmismo (magari mi sbaglio io), ma è improbabile che qualcuno si metta a sniffare e decriptare i pacchetti in giro a caso... dovrebbe essere qualcuno che "vede" i pacchetti passare, e questo penso sia fattibile facilmente soltanto all'interno di una lan (ad esempio con wireshark).

Ah, se conoscete dei modi per vedere i pacchetti di server "remoti", fate sapere qua anche se non credo si possa fare .

Ciao!

[karl94]

Attualmente anche il pannello di controllo è sotto HTTPS (finalmente, aggiungerei), inoltre è supportato il protocollo TLS anche per l'FTP.
Tutte le varie implementazioni però (per quanto ho potuto verificare io, almeno) non presentano la vulnerabilità attualmente.

In ogni caso non ho capito perché c'é tutto questo allarmismo (magari mi sbaglio io)

Il problema di questa vulnerabilità non c'entra con l'intercettazione del traffico dei pacchetti, almeno non direttamente. Quella in questione è una vulnerabilità che permette ad un malintenzionato di leggere porzioni di memoria della macchina remota. È grave in quanto nelle porzioni di memoria (memoria virtuale del processo che usa la libreria OpenSSL, ovviamente, non tutta la memoria della macchina) trafugate può esserci di tutto come password, identificativi di sessione e perfino le chiavi private usate dal server per instaurare le connessioni cifrate. Ottenere quest'ultima informazione in particolare permetterebbe di fingersi il server autentico, e addirittura decifrare tutto il traffico avvenuto mediante quelle chiavi, anche passato, a meno che il server in questione non utilizzasse Perfect Forward Secrecy.
La vulnerabilità è stata introdotta più di due anni fa in un commit che andava ad implementare l'estensione Heartbeat. Quest'ultima consiste praticamente nella definizione di due nuovi tipi di messaggio, uno di richiesta e l'altro di risposta, costituiti da quattro campi: un byte che indica il tipo (richiesta o risposta), due byte per la lunghezza del payload, il payload stesso ed un eventuale padding. Il tutto è poi incapsulato in quello che nelle specifiche viene chiamato TLSPlaintext record, che è ciò che viene effettivamente inviato nello stream TCP (o in un altro protocollo di trasporto usato nello specifico), ed ha un proprio campo di lunghezza. Ed il problema sta proprio in questi capi che indicano la lunghezza dei dati: quando un peer (client o server che sia) riceve un messaggio di tipo heartbeat_request questo deve rispondere con un heartbeat_response contenente lo stesso payload. Ma uno volendo può inviare un TLSPlaintext record regolare, contenente un heartbeat_request irregolare, riportante una lunghezza del payload maggiore di quella reale. In questo caso le specifiche indicano che il messaggio debba venire scartato ed ignorato, ma l'implementazione non è corretta e non effettua alcuna verifica sulla lunghezza riportata, quindi quando va a costruire il messaggio di riposta (vedi ssl/d1_both.c#1480) va a scrivere un payload tanto lungo quanto era indicato nella richiesta, e i dati che ci inserisce li copia a partire dal puntatore che indica l'inizio del payload nella richiesta originale.
Un malintenzionato può dunque costruire un messaggio heartbeat_request con il campo lunghezza impostato al suo valore massimo 0xFFFF e addirittura nessun payload o padding, e la risposta conterrà 65535 byte di dati prelevati dalla zona di memoria utilizzata per le allocazioni dinamiche, e ad ogni pacchetto inviato la risposta potrebbe contenere dati letti da porzioni di memoria differenti.

ma è improbabile che qualcuno si metta a sniffare e decriptare i pacchetti in giro a caso... dovrebbe essere qualcuno che "vede" i pacchetti passare, e questo penso sia fattibile facilmente soltanto all'interno di una lan (ad esempio con wireshark).

Dipende dal tipo di LAN, se è cablata è necessario avere l'accesso fisico, ma se è ad esempio una WLAN, se è aperta o "protetta" con WEP allora il tutto è facilmente intercettabile.

Comunque, per i maniaci della sicurezza come me che vorrebbero cercare di capire cosa significa veramente tutta quella roba con poco senso apparente che ho scritto sopra, una breve ricerca vi avrebbe condotto ai seguenti indirizzi:
http://heartbleed.com/
http://blog.existentialize.com/diagn...bleed-bug.html
http://blog.cloudflare.com/answering...ing-heartbleed
http://blog.leafsr.com/2014/04/11/my...-are-bleeding/
http://www.troyhunt.com/2014/04/ever...now-about.html
http://filippo.io/Heartbleed/

Heartbleed spiegato in un fumetto: http://xkcd.com/1354/

Anch'io quindi mi unisco alla domanda: i nostri dati (leggasi password, che tra l'altro ho già cambiato) sono stati potenzialmente messi in pericolo da tale vulnerabilità su AlterVista?

P.s.: se non erro AlterVista è femmina.

[alemoppo]

Ah comunque, c'é una paginetta di un 19 enne italiano che testa i siti.

(essendo società, av è femminile, anche se Banzai essendo un gruppo, è maschile).

Ciao!

[Gianluca]

I pannelli di controllo/phpmyadmin, erogati sotto https non sono né sono mai stati interessati dal problema dal momento che non utilizzano la libreria openssl colpita dal bug, lo stesso vale per i server ftp e il servizio https per i siti.

Ogni istanza della libreria openssl 1.0.1 precedente alla 1.0.1g (ovvero interessata dal problema) presente su AlterVista è stata comunque aggiornata immediatamente non appena il bug è stato scoperto, non ci sono quindi attualmente componenti su AlterVista che ne facciano uso, né riteniamo ci siano rischi di compromissione di informazioni sensibili.

Non è quindi strettamente necessario cambiare la propria password, sebbene sia sempre consigliabile farlo di tanto in tanto come buona prassi di sicurezza.

[tecnomente]

Grazie a tutti per le risposte, specialmente a karl per la spiegazione della falla e a Gianluca per la chiarificazione riguardo AlterVista :-)

Comunque ho appeno ricevuto un'email da CloudFlare in cui si dice che loro avevano già risolto il problema una settimana prima che fosse reso noto!