eMudhra: chiavi CA banali, revoche e trust store da aggiornare

Dopo il dirottamento dei ccTLD .gh, .sl e .as, che ha permesso di ottenere certificati validi per domini altrui, la fiducia in HTTPS è di nuovo sotto pressione, questa volta dall’interno di un’autorità di certificazione. Otto CA intermedie dell’indiana eMudhra avevano chiavi private così deboli da poter essere ricavate in meno di un secondo dai certificati pubblici. Con una di queste chiavi si può firmare un certificato per qualsiasi dominio, accettato da tutti i client che si fidano ancora di quelle CA.

Cosa è successo

Il 17 ottobre 2026 alle 20:06 UTC Mozilla ha ricevuto, inoltrata dal Chrome Root Program, la segnalazione di un ricercatore che si firma «Wayne». Secondo Help Net Security, l’ha scoperto controllando i dati pubblici del Common CA Database (CCADB) e, come prova, ha firmato con ogni chiave il messaggio «We have a problem here – Wayne», inviandolo ad Apple, Google, Microsoft, Mozilla ed eMudhra. Mozilla ha ricavato le chiavi in autonomia alle 21:48 UTC dello stesso giorno, senza conoscere il metodo del ricercatore.

La risposta, secondo SecurityWeek e Help Net Security:

• 17 ottobre: Firefox blocca le intermedie con OneCRL e Chrome blocca le sei intermedie TLS con i CRLSet, senza aggiornare né riavviare il browser; Android e Chromebook ricevono un blocco equivalente tramite Google Play Services;
• 18 ottobre: eMudhra revoca gli otto certificati;
• 19 ottobre: Apple distribuisce le protezioni; Cloudflare, informata quel giorno, aggiorna i suoi servizi e client e non rileva sfruttamenti;
• 20 ottobre: Microsoft blocca i certificati; Mozilla pubblica Firefox 158.0.1 e aggiornamenti ESR per le configurazioni che non avevano ricevuto il blocco. Ars Technica riferiva però che, quel giorno, Edge su Windows 10 si collegava ancora a 12 host vulnerabili.

Mozilla ha tolto la fiducia alla radice emSign ECC Root CA – G3, che firma le intermedie; secondo CSO Online, Google la toglie dal Chrome Root Store con effetto su tutti i dispositivi dal 27 ottobre. eMudhra ha smesso di emettere sotto quella radice e stima circa 30.000 certificati di clienti da sostituire (la stessa cifra è indicata a CSO Online da Yash Kadakia di Security Brigade).

Dettagli tecnici

Secondo il rapporto di Mozilla citato dalle testate, le otto intermedie provengono da un lotto di 24 generato il 30 aprile 2025: sei emettono certificati TLS, due servono alla firma del codice. Help Net Security scrive che Sectigo le ha firmate in modo incrociato tutte e otto a maggio 2025; BleepingComputer parla solo di «alcune».

Una chiave privata ECC P-384 dovrebbe essere un numero casuale di 384 bit. Quelle di eMudhra erano tutte inferiori a 256: 4, 56, 66, 115, 155, 156, 230 e 237. Dennis Jackson di Mozilla le descrive come «tutti zeri tranne l’ultimo byte», recuperabili quasi istantaneamente con l’algoritmo del logaritmo discreto baby-step giant-step; ma basta anche provare i 256 valori possibili. Più persone le hanno ricavate in modo indipendente e una è stata pubblicata su GitHub.

La spiegazione di eMudhra: nella cerimonia di generazione delle chiavi, con HSM FIPS 140-2 Livello 3, un errore dello script ha fatto produrre a un passaggio di wrap/unwrap un secondo insieme di chiavi deboli accanto a quelle corrette. Le chiavi deboli avevano etichette simili e sono state scelte per le richieste di certificato. L’azienda ammette errori umani in più passaggi; dice che le intermedie erano destinate ai suoi data center negli Stati Uniti e in Europa, che solo una è entrata in produzione, che nessuna ha emesso certificati finali e che le chiavi delle radici non sono coinvolte. Ricorda che radici e intermedie avevano superato audit indipendenti per due anni e ricontrollerà tutte le cerimonie svolte.

Google afferma che nei log di Certificate Transparency (CT) non risultano certificati TLS legati alle sei intermedie prima del blocco, quindi i client che applicano la CT, come Chrome nella configurazione predefinita, non potevano essere colpiti. Non tutti i client però applicano la CT, e chi possedeva una chiave poteva firmare certificati senza passare da eMudhra: non si sa se qualcuno l’abbia fatto nei 17 mesi precedenti. Le fonti non dettagliano l’impatto delle due intermedie per la firma del codice.

Per sfruttare un certificato falso serve un attacco adversary-in-the-middle: secondo Ars Technica è alla portata di attori con molte risorse, ma molto più facile per chi controlla una rete locale.

MITRE ATT&CK (classificazione nostra): T1588.004 (Obtain Capabilities: Digital Certificates), T1557 (Adversary-in-the-Middle), T1553.002 (Subvert Trust Controls: Code Signing) per le intermedie di firma del codice.

Impatto per le aziende europee e italiane

I browser sono protetti, il resto no. Applicazioni con un proprio elenco di radici, server, container e dispositivi che non controllano la revoca possono fidarsi ancora delle intermedie finché non vengono aggiornati. Filippo Valsorda, intervistato da Ars Technica, prevede una «coda lunghissima»: dispositivi IoT, container Docker, macchine Linux dimenticate, strumenti a riga di comando con una copia propria delle radici.

Per i soggetti NIS2 è un caso concreto di rischio della catena di fornitura: la fiducia dipende da terze parti mai scelte direttamente. In sanità e nell’industria pesano gli apparati con cicli di aggiornamento lunghi. Chi ha certificati eMudhra sotto la radice G3 deve sostituirli prima della rimozione dai root store.

Cosa fare subito

1. Aggiorna i pacchetti delle radici. Lo stato al 20 ottobre, dal tracker di Jackson riportato da BleepingComputer, tra gli altri: Ubuntu ca-certificates 20260816ubuntu0.*.1, Alpine 20261020-r0, Arch ca-certificates-mozilla 3.131.1-1, NSS 3.131.1, Python certifi 2026.10.19, pip 26.2.2, rustls-webpki 0.103.16, webpki-roots 1.0.10, Electron 44.9.1, 43.8.1 e 42.11.16, Composer ca-bundle 1.4.16 e 1.6.0; Go 1.27.3 e 1.26.10 (CVE-2026-111943, citata solo da BleepingComputer). Debian, FreeBSD, Node.js e Bun erano ancora in attesa.
2. Ricostruisci immagini e container con le radici aggiornate: una copia incorporata non si aggiorna da sola.
3. Cerca i trust store separati, come suggerisce Kadakia: gateway di pagamento, integrazioni con fornitori, vecchie applicazioni Java, app mobili, apparati di rete. Su macOS, secondo Jackson, /usr/bin/curl può continuare a fidarsi perché non controlla la revoca.
4. Verifica che i client rifiutino le catene compromesse, comprese quelle con firma incrociata, usando gli endpoint di prova del sito di Jackson.
5. Sostituisci i certificati eMudhra emessi sotto emSign ECC Root CA – G3 per i tuoi servizi.
6. Monitora i log CT per i tuoi domini, come già indicato per il caso dei ccTLD.

Come aiuta ARXDOME

ARX Expose mostra ogni giorno la superficie d’attacco esterna, compresi nomi e certificati dei servizi pubblici: aiuta a trovare quelli da sostituire. Sulle sedi approvate, la scansione attiva di ARX Watch identifica i certificati dei dispositivi interni, anche di quelli senza sonda.

Ultimo aggiornamento: 22 ottobre 2026