EN flag
Listino Supporto Partner Contatti 800 13.40.41

Articoli

Icona delle News




Il Bug Heartbleed – I vecchi Bug sono duri a morire

12/10/20 CoreTech Blog

Si potrebbe pensare che dopo diversi anni una nota vulnerabilità di sicurezza non dovrebbe più essere trovata nei sistemi di produzione. Potrebbe quindi essere una sorpresa che famosi problemi di sicurezza Internet come la vulnerabilità Heartbleed persistano per molti anni dopo che sono stati risolti. Non ci credi? 

Ci sono molte ragioni per cui i vecchi insetti sono duri a morire. Continua a leggere per saperne di più su Heartbleed e su alcuni dei motivi per cui questo bug e molti altri rimangono non risolti in così tanti sistemi.

La storia di Heartbleed

Come per molte gravi vulnerabilità di sicurezza, Heartbleed non è stato scoperto immediatamente. Questa falla di sicurezza è stata introdotta nella versione 1.0.1 della libreria OpenSSL nel 2012 insieme all'estensione Heartbeat. Le versioni vulnerabili di OpenSSL erano OpenSSL dalla 1.0.1 alla 1.0.1f.

La vulnerabilità è stata scoperta due anni dopo (nell'aprile 2014) dai ricercatori di sicurezza di Google e da una società di sicurezza indipendente chiamata Codenomicon , e successivamente classificata come CVE-2014-0160. Per due anni, il bug è stato un segreto e probabilmente non sapremo mai se qualcuno ne abbia mai approfittato.

Heartbleed è stato risolto dagli sviluppatori del software OpenSSL molto rapidamente: entro una settimana è stato rilasciato OpenSSL 1.0.1g e tutto ciò che era necessario era solo un aggiornamento software per tutti i server interessati. Tuttavia, questa era solo una prova di quanto possa essere difficile aggiornare software ampiamente diffuso: la maggior parte delle implementazioni di TLS su Internet utilizzava la libreria OpenSSL (fortunatamente, non Microsoft), inclusi Apache, nginx e alcuni dispositivi di aziende come come Cisco e Apple. La vulnerabilità ha interessato anche siti come Yahoo.

Come funziona Heartbleed

Per capire Heartbleed, dobbiamo prima capire Heartbeat.

Heartbeat è un'estensione della libreria OpenSSL. La libreria OpenSSL è un progetto open source per l'implementazione di Transport Layer Security e Secure Sockets Layer (SSL / TLS) oltre a DTLS . Questa libreria viene utilizzata dalla maggior parte degli altri software che richiedono TLS per comunicazioni protette, ad esempio server Web, server di posta e altro.

L'estensione Heartbeat è stata introdotta per verificare se la connessione TLS è ancora disponibile. È un meccanismo molto semplice: il client invia un messaggio speciale chiamato messaggio heartbeat al server. Questo messaggio contiene dati e ne specifica la dimensione. In risposta, il server dovrebbe inviare la stessa richiesta di heartbeat con gli stessi dati e la stessa dimensione dei dati. Questo meccanismo è stato proposto in RFC 6520 .

Tuttavia, gli sviluppatori hanno commesso un errore e non hanno introdotto un controllo se la dimensione dei dati specificati nel messaggio Heartbeat rappresenta la quantità effettiva di dati. Risulta che nell'implementazione originale di Heartbeat, il client potrebbe dichiarare qualsiasi dimensione di dati e il server lo considererebbe valido.

La vulnerabilità appare se la dimensione dichiarata supera la dimensione reale dei dati. In tal caso, il server restituisce il messaggio con informazioni aggiuntive:

  1. Richiesta del cliente: 1 byte di dati reali, dimensione dichiarata: 200 byte.
  2. Risposta del server: 200 byte di dati (1 byte originale + 199 byte dalla memoria adiacente), dimensione: 200 byte.

Simile a tali vulnerabilità come l' overflow del buffer , l'attaccante riceve contenuti di memoria casuali, che possono, per puro caso, includere informazioni personali e / o informazioni sensibili come chiavi segrete comprese chiavi private e chiavi di crittografia simmetriche, certificati SSL, numeri di carte di credito, ecc. .

Motivi per cui i vecchi bug persistono

La persistenza del bug Heartbleed è una buona opportunità per analizzare perché i vecchi bug sono così difficili da eliminare. Ecco alcuni motivi comuni:

  • Il software vulnerabile viene utilizzato in un dispositivo hardware. Questa è molto probabilmente la ragione principale alla base del numero di risultati nel rapporto Shodan menzionato all'inizio di questo articolo. Molti dispositivi IoT utilizzano OpenSSL per la gestione di TLS e tali dispositivi introdotti tra il 2012 e il 2014 sarebbero vulnerabili a Heartbleed. Alcuni di essi potrebbero non disporre di aggiornamenti del firmware e, nel caso di altri, i proprietari dei dispositivi potrebbero scegliere di non eseguire tali aggiornamenti.
  • Un'azienda utilizza una versione personalizzata del software vulnerabile. Nel caso di Heartbleed, OpenSSL è una libreria open source e alcune aziende potrebbero averla modificata per i loro scopi. In questi casi, una patch diretta non è possibile: l'azienda deve quindi reintrodurre il proprio codice personalizzato nella nuova versione della libreria. Questo è spesso il motivo per cui i software web open source come WordPress non vengono aggiornati immediatamente dalle aziende anche se vengono rilevati nuovi bug critici.
  • Semplice negligenza: le piccole aziende potrebbero semplicemente non essere nemmeno consapevoli del fatto che il software che utilizzano necessita di un aggiornamento di sicurezza perché non tutto il software dispone di aggiornamenti automatici. Se, ad esempio, assumessero una società esterna per configurare un server web e poi nessuno lo amministra, non saprebbero nulla su come proteggerlo.
  • Valutazione del rischio: alcune aziende possono decidere che il rischio di essere violate e le potenziali ripercussioni non valgono la pena di applicare un aggiornamento di sicurezza. Può darsi che, ad esempio, la risorsa web abbia un'importanza commerciale prossima allo zero, non sia in alcun modo collegata ad altre risorse e non contenga alcun dato sensibile.
  • Sovraccarico di lavoro e priorità: se l'azienda ha molte vulnerabilità software da gestire e un team limitato per risolverle, è necessaria la definizione delle priorità e alcuni bug possono essere rimandati a lungo solo perché non sono considerati bloccanti. Questa è una realtà che molte società di sviluppo web devono affrontare: i nuovi bug di sicurezza spesso superano quelli che vengono corretti in un determinato periodo di tempo.

Tutto sommato, il bug Heartbleed è un eccellente esempio del motivo per cui la scansione della sicurezza è solo la punta dell'iceberg e deve essere associato alla gestione delle vulnerabilità per garantire la sicurezza IT, sia che si tratti della sicurezza della rete (come con Heartbleed) di sicurezza web.

Banner

Articoli su Sicurezza

Cos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàCome eseguire il benchmark di uno scanner di vulnerabilità Web?5 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft