eMudhra: chei CA banale, revocări și trust store de actualizat

După deturnarea ccTLD-urilor .gh, .sl și .as, care a permis obținerea de certificate valide pentru domeniile altora, încrederea în HTTPS este din nou sub presiune, de data aceasta din interiorul unei autorități de certificare. Opt CA intermediare ale companiei indiene eMudhra aveau chei private atât de slabe încât puteau fi recuperate în mai puțin de o secundă din certificatele publice. Cu una dintre aceste chei se poate semna un certificat pentru orice domeniu, acceptat de toți clienții care încă au încredere în acele CA.

Ce s-a întâmplat

Pe 17 octombrie 2026, la 20:06 UTC, Mozilla a primit, redirecționată de Chrome Root Program, sesizarea unui cercetător care semnează „Wayne”. Potrivit Help Net Security, acesta a descoperit problema verificând datele publice din Common CA Database (CCADB) și, ca dovadă, a semnat cu fiecare cheie mesajul „We have a problem here – Wayne”, pe care l-a trimis către Apple, Google, Microsoft, Mozilla și eMudhra. Mozilla a recuperat cheile independent la 21:48 UTC în aceeași zi, fără să cunoască metoda cercetătorului.

Reacția, potrivit SecurityWeek și Help Net Security:

• 17 octombrie: Firefox blochează intermediarele prin OneCRL, iar Chrome blochează cele șase intermediare TLS prin CRLSets, fără actualizarea sau repornirea browserului; Android și Chromebook primesc o blocare echivalentă prin Google Play Services;
• 18 octombrie: eMudhra revocă cele opt certificate;
• 19 octombrie: Apple distribuie protecțiile; Cloudflare, informată în aceeași zi, își actualizează serviciile și clienții și nu constată exploatări;
• 20 octombrie: Microsoft blochează certificatele; Mozilla publică Firefox 158.0.1 și actualizări ESR pentru configurațiile care nu primiseră blocarea. Ars Technica relata însă că, în acea zi, Edge pe Windows 10 se mai conecta încă la 12 hosturi vulnerabile.

Mozilla a retras încrederea în rădăcina emSign ECC Root CA – G3, care semnează intermediarele; potrivit CSO Online, Google o elimină din Chrome Root Store, cu efect pe toate dispozitivele de la 27 octombrie. eMudhra a oprit emiterea sub această rădăcină și estimează că trebuie înlocuite aproximativ 30.000 de certificate ale clienților (aceeași cifră este oferită pentru CSO Online de Yash Kadakia, de la Security Brigade).

Detalii tehnice

Potrivit raportului Mozilla citat de presă, cele opt intermediare provin dintr-un lot de 24 generat pe 30 aprilie 2025: șase emit certificate TLS, două servesc la semnarea codului. Help Net Security scrie că Sectigo le-a semnat încrucișat pe toate opt în mai 2025; BleepingComputer vorbește doar de „unele”.

O cheie privată ECC P-384 ar trebui să fie un număr aleatoriu de 384 de biți. Cheile eMudhra erau toate mai mici de 256: 4, 56, 66, 115, 155, 156, 230 și 237. Dennis Jackson, de la Mozilla, le descrie ca fiind „practic numai zerouri, cu excepția ultimului octet”, recuperabile aproape instantaneu cu algoritmul de logaritm discret baby-step giant-step; ajunge însă și să încerci cele 256 de valori posibile. Mai multe persoane le-au recuperat independent, iar una a fost publicată pe GitHub.

Explicația eMudhra: în ceremonia de generare a cheilor, cu HSM-uri FIPS 140-2 Nivel 3, o eroare a scriptului a făcut ca un pas de wrap/unwrap să producă un al doilea set de chei slabe alături de cele corecte. Cheile slabe aveau etichete asemănătoare și au fost alese pentru cererile de certificat. Compania recunoaște erori umane în mai mulți pași; spune că intermediarele erau destinate centrelor sale de date din Statele Unite și Europa, că doar una a intrat în producție, că niciuna nu a emis certificate finale și că cheile rădăcinilor nu sunt afectate. Amintește că rădăcinile și intermediarele trecuseră audituri independente doi ani la rând și va reverifica toate ceremoniile efectuate.

Google afirmă că în jurnalele Certificate Transparency (CT) nu apar certificate TLS legate de cele șase intermediare înainte de blocare, deci clienții care aplică CT, precum Chrome în configurația implicită, nu puteau fi vizați. Nu toți clienții aplică însă CT, iar cine deținea o cheie putea semna certificate fără să treacă prin eMudhra: nu se știe dacă cineva a făcut-o în cele 17 luni anterioare. Sursele nu detaliază impactul celor două intermediare pentru semnarea codului.

Pentru a exploata un certificat fals este nevoie de un atac adversary-in-the-middle: potrivit Ars Technica, este la îndemâna actorilor cu multe resurse, dar mult mai ușor pentru cine controlează o rețea locală.

MITRE ATT&CK (clasificarea noastră): T1588.004 (Obtain Capabilities: Digital Certificates), T1557 (Adversary-in-the-Middle), T1553.002 (Subvert Trust Controls: Code Signing) pentru intermediarele de semnare a codului.

Impactul pentru companiile europene și italiene

Browserele sunt protejate, restul nu. Aplicațiile cu propria listă de rădăcini, serverele, containerele și dispozitivele care nu verifică revocarea pot avea încă încredere în intermediare până la actualizare. Filippo Valsorda, intervievat de Ars Technica, anticipează o „coadă foarte lungă”: dispozitive IoT, containere Docker, mașini Linux uitate, instrumente în linie de comandă cu propria copie a rădăcinilor.

Pentru entitățile NIS2 este un caz concret de risc în lanțul de aprovizionare: încrederea depinde de terți pe care nu i-au ales niciodată direct. În sănătate și în industrie contează echipamentele cu cicluri lungi de actualizare. Dacă ai certificate eMudhra sub rădăcina G3, trebuie să le înlocuiești înainte ca rădăcina să fie eliminată din trust store-uri.

Ce să faci imediat

1. Actualizează pachetele de rădăcini. Situația la 20 octombrie, din trackerul lui Jackson citat de BleepingComputer, printre altele: 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 și 42.11.16, Composer ca-bundle 1.4.16 și 1.6.0; Go 1.27.3 și 1.26.10 (CVE-2026-111943, citată doar de BleepingComputer). Debian, FreeBSD, Node.js și Bun erau încă în așteptare.
2. Reconstruiește imaginile și containerele cu rădăcinile actualizate: o copie încorporată nu se actualizează singură.
3. Caută trust store-urile separate, cum sugerează Kadakia: gateway-uri de plată, integrări cu furnizori, aplicații Java vechi, aplicații mobile, echipamente de rețea. Pe macOS, potrivit lui Jackson, /usr/bin/curl poate avea în continuare încredere, pentru că nu verifică revocarea.
4. Verifică faptul că clienții resping lanțurile compromise, inclusiv cele semnate încrucișat, cu endpoint-urile de test de pe site-ul lui Jackson.
5. Înlocuiește certificatele eMudhra emise sub emSign ECC Root CA – G3 pentru serviciile tale.
6. Monitorizează jurnalele CT pentru domeniile tale, cum am recomandat deja în cazul ccTLD-urilor.

Cum ajută ARXDOME

ARX Expose îți arată zilnic suprafața de atac externă, inclusiv numele și certificatele serviciilor publice: te ajută să le găsești pe cele de înlocuit. În locațiile aprobate, scanarea activă ARX Watch identifică certificatele dispozitivelor interne, inclusiv ale celor fără sondă.

Ultima actualizare: 22 octombrie 2026