Chiavi private da 1 byte per otto certificati CA: la minaccia che può impersonare qualsiasi dominio
Scoperta la vulnerabilità di otto certificati intermedi con chiavi da 1 byte, che permette a un attaccante di impersonare qualsiasi sito o firmare malware. Ecco l’impatto e le contromisure.
Tom’s Hardware ha segnalato una falla senza precedenti: otto certificati intermedi rilasciati dalla CA indiana eMudhra presentano chiavi private di appena un byte, rendendo possibile per un aggressore impersonare qualsiasi dominio o firmare software come se fosse legittimo. La scoperta, avvenuta questa settimana, costringe amministratori di sistema di tutto il mondo a una corsa contro il tempo per aggiornare sistemi operativi, browser e applicazioni.
- Numero di certificati compromessi: otto (sei TLS, due code-signing).
- Dimensione della chiave privata: 1 byte (valori da 0 a 255), triviale da forzare.
- Impatto potenziale: possibilità di spoofing di qualsiasi sito web o di distribuire malware firmato da Microsoft o Google.
- Azioni richieste: revoca immediata dei certificati, aggiornamento delle liste di fiducia e verifica del supporto a Certificate Transparency.
Che cosa è successo: la vulnerabilità delle chiavi da 1 byte
eMudhra ha emesso sei certificati TLS e due certificati di firma codice con chiavi private estremamente deboli: una singola cifra esadecimale. In pratica, un attaccante può indovinare la chiave in una frazione di secondo, ricostruire la catena di fiducia e far passare qualsiasi traffico HTTPS o software come proveniente da una fonte affidabile. La causa è ancora oggetto di indagine, ma la gravità è evidente: la sicurezza della PKI (Public Key Infrastructure) si basa proprio sulla robustezza delle chiavi private.
Impatto su sistemi e software: cosa aggiornare
La vulnerabilità non riguarda solo i browser. Qualsiasi componente che verifica la catena di certificati è a rischio: sistemi operativi (Windows, macOS, Linux), client di posta, gestori di pacchetti, ambienti di sviluppo (Python, Go, Node.js, Rust) e persino dispositivi IoT. Anche le soluzioni di containerizzazione come Docker, le macchine virtuali e i router legacy devono ricevere aggiornamenti delle liste di revoca (CRL) o dei certificati di fiducia (trust store).
Come difendersi: le contromisure immediate
Le versioni più recenti di Chrome, Brave, Firefox e Safari supportano già Certificate Transparency (CT) e bloccano certificati non registrati nei log pubblici, mitigando il rischio per la navigazione web. Tuttavia, è fondamentale:
- Applicare tutti gli aggiornamenti di sicurezza rilasciati da Microsoft, Apple, Google e dai distributori Linux.
- Verificare che le liste di revoca siano aggiornate; in caso contrario, forzare un refresh manuale.
- Disabilitare temporaneamente certificati sospetti in ambienti critici, se possibile.
- Monitorare i log di CT per eventuali certificati emessi da eMudhra non autorizzati.
Il punto di vista di AllFounds: cosa cambia davvero
Questa vulnerabilità dimostra quanto la sicurezza della catena di certificazione sia delicata. In Italia, le imprese che gestiscono dati sensibili – banche, sanità, pubblica amministrazione – devono trattare la questione con la massima urgenza. La buona notizia è che i principali browser hanno già una difesa efficace grazie a Certificate Transparency; tuttavia, la maggior parte dei sistemi legacy e dei dispositivi IoT non dispone di tale meccanismo. Consiglio di avviare subito un audit dei trust store presenti nei server e nei dispositivi di rete, di verificare la presenza di aggiornamenti per le librerie di crittografia (OpenSSL, LibreSSL, BoringSSL) e di pianificare una revisione periodica delle CA di fiducia. Solo così si potrà limitare il rischio di attacchi di spoofing su larga scala.
Domande frequenti
Quali sistemi sono a rischio?
Tutti i dispositivi che si affidano a certificati intermedi per stabilire connessioni TLS o per verificare firme di codice: PC, server, smartphone, tablet, router, dispositivi IoT, macchine virtuali e container.
Come verificare se il mio software è stato aggiornato?
Controllare le versioni dei sistemi operativi e dei browser rispetto alle ultime release di sicurezza pubblicate. Per le librerie di crittografia, eseguire openssl version -a o l’equivalente e confrontare il risultato con le note di rilascio dei fornitori. Infine, consultare le liste di revoca (CRL) o i certificati di fiducia (trust store) per assicurarsi che i certificati compromessi siano stati rimossi.
