Una chiave dei certificati eMudhra era il numero 4 e bastava a falsificare qualsiasi sito

La chiave segreta di uno dei certificati che attestano l’identità di un sito web si è rivelata essere il numero quattro. Non un lungo numero casuale che per caso comincia con quattro: proprio quattro. Altre sette chiavi della stessa autorità di certificazione indiana, eMudhra, erano quasi altrettanto semplici. Chiunque ne fosse entrato in possesso avrebbe potuto creare un certificato per qualsiasi sito, da una banca a un servizio di posta elettronica, e i software che si fidano di eMudhra lo avrebbero accettato come autentico.

Sono questi i certificati che il lucchetto nel browser verifica. Con un certificato contraffatto, un aggressore che si interpone tra te e Internet — su una rete Wi-Fi di un bar, attraverso un router compromesso o sfruttando una rete nazionale ostile — può spacciarsi per il sito vero e leggere o modificare ciò che invii. Chrome, Firefox, Safari e le piattaforme Microsoft hanno già smesso di fidarsi degli otto certificati. Ma su molti altri software installati sui tuoi dispositivi non è ancora così.

Una normale chiave di questo tipo è un numero casuale lungo circa 384 bit, con all’incirca 10 elevato alla potenza di 115 possibilità. Le chiavi di eMudhra erano lunghe da 3 a 8 bit: 4, 56, 66, 115, 155, 156, 230 e 237, secondo l’elenco pubblicato da Ars Technica. Il ricercatore di sicurezza Scott Helme ha scritto di aver recuperato tutte e otto dai certificati pubblici presenti sul suo laptop, «e ci è voluto meno di un secondo». In seguito ha aggiunto che anche Claude, il modello di Anthropic, ci è riuscito con un solo prompt.

Non è stato necessario rubare nulla. Nella sua ricostruzione inviata a Mozilla e riportata da BleepingComputer, eMudhra ha attribuito il problema a un bug nello script utilizzato durante la procedura di generazione delle chiavi: lo script ne aveva create altre, deboli, e i dipendenti le avevano selezionate per errore perché le etichette erano simili. L’azienda, che dichiara di aver emesso oltre 60 milioni di certificati digitali, ha riferito a Mozilla che la maggior parte delle autorità intermedie coinvolte non è mai entrata in produzione e che non ha trovato prove del loro impiego per firmare certificati destinati agli utenti finali. Ha revocato tutte e otto le chiavi e interrotto le emissioni tramite la radice interessata.

Con i browser, la parte più semplice è già sistemata. Chrome, Firefox e Safari aggiornano silenziosamente gli elenchi di revoca e richiedono inoltre che ogni certificato compaia nei registri pubblici Certificate Transparency. Nessun certificato di sito web riconducibile a queste chiavi è mai apparso nei registri, quindi i browser aggiornati non sono stati esposti per impostazione predefinita. Il problema riguarda tutto il resto. Strumenti a riga di comando come curl, linguaggi come Python, Node e Go, client VPN, container Docker e dispositivi per la smart home hanno elenchi autonomi di autorità fidate, controllano di rado le revoche e ignorano i registri di trasparenza. Helme ha creato un certificato falso per l’API dei pagamenti di Stripe e ha scoperto che curl, Python e Node lo accettavano su tutte le macchine Linux e macOS che ha testato.

«Sarà un lavoro di bonifica enorme, più grande di Heartbleed», ha dichiarato ad Ars Technica Filippo Valsorda, responsabile della manutenzione del codice crittografico del linguaggio Go, ricordando la vulnerabilità di OpenSSL che ha richiesto anni per essere risolta. Si aspetta «una coda lunghissima» di dispositivi IoT, container Docker, macchine Linux dimenticate e strumenti non più mantenuti che includono una propria copia delle autorità radice fidate. Per sfruttare le chiavi, l’aggressore deve comunque trovarsi lungo il percorso della rete: un’eventualità alla portata di governi, di chi riesce a compromettere la rete di un ufficio o di chi gestisce un hotspot pubblico. Signal, WhatsApp e WireGuard, che non si affidano a questi certificati per la crittografia, non sono coinvolti, osserva Ars.

Le chiavi erano recuperabili sin dal momento in cui i certificati sono stati creati, nell’aprile 2025: una finestra di circa 17 mesi. Non è possibile sapere se qualcuno le abbia utilizzate contro software che salta il controllo dei registri di trasparenza. Nel maggio 2025 ogni certificato è stato inoltre controfirmato dalla radice AAA Certificate Services di Sectigo, ampliando così il numero di sistemi che si fidavano di quei certificati.

Per la maggior parte delle persone, la soluzione consiste nell’installare gli aggiornamenti. Un ricercatore ha segnalato le chiavi ai produttori di browser il 17 ottobre. Mozilla ha bloccato i certificati in Firefox entro tre ore, quello stesso giorno, e il 20 ottobre ha distribuito Firefox 158.0.1, nuove versioni ESR e NSS 3.131.1, che rimuove la radice eMudhra. Secondo il sito dedicato all’incidente, curato dall’ingegnere Mozilla Dennis Jackson, Apple ha aggiunto protezioni il 19 ottobre e Microsoft il 20; al momento della pubblicazione, però, Ars ha rilevato che Edge su Windows 10 continuava a collegarsi ai server di prova. Sono disponibili Go 1.27.3 e 1.26.10, pip 26.2.2, uv 0.13.4 e certifi 2026.10.19; Cloudflare ha aggiornato le app WARP e 1.1.1.1, mentre le distribuzioni Linux stanno ancora distribuendo nuovi pacchetti ca-certificates. Il curl integrato in macOS continua a fidarsi delle chiavi finché il relativo file dei certificati non viene modificato manualmente.

Chrome ha confermato che la radice eMudhra sarà rimossa dal Chrome Root Store con la versione 43. Finché tutti i dispositivi non saranno aggiornati, bastano otto bit a separare molti software di uso quotidiano da una convincente imitazione di qualsiasi sito.

Tag: cybersicurezza, Mozilla, Firefox, certificati TLS, crittografia, eMudhra