ccTLD-urile .gh, .sl și .as deturnate: certificate Google

📌 Evoluții ulterioare: Node.js: zece vulnerabilități corectate, patru de risc ridicat (21 octombrie 2026) · eMudhra: chei CA banale, revocări și trust store de actualizat (20 octombrie 2026)

Pe 6 octombrie 2026, Chrome Secure Web and Networking Team de la Google a făcut publică o serie de atacuri împotriva a trei domenii naționale de prim nivel (ccTLD): .gh (Ghana), .sl (Sierra Leone) și .as (Samoa Americană). În timpul deturnărilor, atacatorii au modificat înregistrări DNS autoritative și au obținut certificate HTTPS neautorizate pentru mai multe domenii Google și pentru domenii ale altor organizații. Google spune că a aflat de atacuri în săptămâna precedentă.

Nu există CVE: problema nu este un defect al unui produs, ci controlul rezolvării numelor în amonte de site-urile afectate.

Ce s-a întâmplat

Potrivit Google, sistemele proprii nu au fost compromise și, având în vedere natura atacurilor, nu există motive să se creadă că autoritățile de certificare (CA) care au emis certificatele au greșit ceva. Google nu a precizat ce domenii au fost afectate și nici câte certificate au fost obținute.

Despre modul în care atacatorii au preluat controlul DNS, sursele rămân generale: Infosecurity Magazine și The Hacker News vorbesc despre compromiterea registrelor celor trei ccTLD, în timp ce declarațiile Google citate de presă vorbesc despre deturnări cu modificarea înregistrărilor DNS autoritative, fără detalii despre tehnică.

Răspunsul Google, potrivit Infosecurity Magazine:

• Chrome a blocat certificatele neautorizate pentru proprietățile Google prin CRLSets, mecanismul cu care browserul blochează rapid certificate în caz de urgență;
• Google a colaborat cu CA-urile emitente pentru revocarea certificatelor, astfel încât să fie protejați și utilizatorii altor clienți;
• jurnalele Certificate Transparency (CT) au scos apoi la iveală alte organizații afectate, printre care mari mărci globale și servicii online foarte folosite: și aceste certificate au fost blocate în Chrome, iar Google a contactat organizațiile, acolo unde a fost posibil.

Detalii tehnice: de ce este suficient un DNS deturnat

Înainte de a emite un certificat, o CA verifică faptul că solicitantul controlează domeniul. Cine controlează înregistrările DNS autoritative poate interfera cu această verificare și poate obține un certificat valid fără a compromite sistemele site-ului. Așa cum subliniază The Register, atacatorul deține atunci atât rutarea traficului (prin DNS), cât și cheia privată a certificatului:

1. utilizatorii care tastează adresa corectă pot ajunge pe o copie a site-ului;
2. browserul nu afișează avertismente, pentru că certificatul provine de la o CA de încredere;
3. atacatorul poate intercepta sau modifica datele trimise către site-ul uzurpat și poate folosi marca pentru phishing sau distribuirea de malware.

Există și un efect care durează mai mult decât atacul. CA-urile pot reutiliza o perioadă o validare a controlului domeniului deja trecută: potrivit Google, chiar și după ce proprietarul a recâștigat controlul DNS, atacatorul ar putea folosi acea validare din cache pentru a obține certificate noi.

MITRE ATT&CK (clasificarea noastră, sursele nu o indică): T1584.001 (Compromise Infrastructure: Domains) pentru deturnare și T1588.004 (Obtain Capabilities: Digital Certificates) pentru certificatele obținute.

Impactul pentru companiile europene și italiene

Riscul direct îi privește pe cei care au domenii sub .gh, .sl sau .as, inclusiv înregistrări regionale sau defensive, adesea parcate și puțin supravegheate. Lecția este însă generală: încrederea în HTTPS depinde de securitatea întregului lanț DNS, de la registru până la furnizorul care găzduiește zona, iar o deturnare în amonte nu lasă urme în sistemele site-ului uzurpat.

Chiar Google avertizează că intervenția din browser nu trebuie considerată o protecție: analiza sa s-ar putea să nu fi identificat toate domeniile afectate, iar blocările din Chrome nu îi protejează în mod fiabil pe cei care folosesc alți clienți.

Pentru entitățile NIS2, registrarii și furnizorii DNS fac parte din lanțul de aprovizionare de care trebuie să țină cont gestionarea riscurilor. Un certificat emis fără autorizare pentru unul dintre domeniile tale este un eveniment de analizat, inclusiv în vederea notificării către CSIRT-ul național.

Ce faci acum

1. Fă inventarul domeniilor tale, inclusiv al celor parcate și al ccTLD-urilor regionale: nu poți supraveghea ceea ce nu cunoști.
2. Monitorizează continuu jurnalele CT pentru toate domeniile: așa afli, aproape în timp real, că cineva a obținut un certificat în numele tău.
3. Dacă ai domenii sub .gh, .sl sau .as, verifică imediat intrările CT recente, în căutarea unor certificate neașteptate.
4. Publică înregistrări CAA restrictive, care indică ce CA pot emite certificate pentru domeniu. Google recomandă să le limitezi și la conturi ACME și metode de validare anume (extensiile accounturi și validationmethods), de exemplu: 0 issue "ca.example; accounturi=https://ca.example/acct/123; validationmethods=dns-01". În timpul unei deturnări active, CAA nu blochează emiterea, pentru că atacatorul controlează și acele înregistrări; odată restabilite, însă, împiedică reutilizarea validărilor din cache pentru obținerea de certificate noi.
5. Nu te baza pe browser ca unică apărare, mai ales pentru utilizatorii și aplicațiile care nu folosesc Chrome.

Google a anunțat și că va continua să lucreze la schimbări în întregul ecosistem HTTPS, printre care reducerea perioadei de valabilitate a certificatelor și a reutilizării validării controlului domeniului.

Cum te ajută ARXDOME

ARX Expose pornește de la domeniile declarate pentru compania ta și le arată suprafața de atac, inclusiv numele și certificatele, cu o verificare zilnică; semnalează și domeniile asemănătoare cu al tău înregistrate de alții, folosite adesea pentru phishing. Cu ARX Horizon poți interoga direct din portal indicatorii de compromitere și reputația unei adrese.

Ultima actualizare: 8 octombrie 2026