Registri ccTLD violati: hacker ottengono certificati HTTPS validi per Google

🛡️ Executive Summary

• Gli attaccanti compromettono i registri .gh, .sl e .as e modificano i record DNS autoritativi senza violare i sistemi Google.
• Il controllo del DNS consente di superare la Domain Validation e ottenere certificati HTTPS tecnicamente validi per domini altrui.
• I CT log mostrano almeno 12 certificati non autorizzati: monitoraggio Certificate Transparency e CAA diventano controlli essenziali.

Google non è stata violata, ma alcuni suoi domini nazionali sono finiti dentro un incidente che mostra quanto la fiducia del web dipenda da infrastrutture esterne al perimetro dei grandi provider. Attaccanti hanno compromesso operatori di registri ccTLD relativi a Ghana, Sierra Leone e Samoa Americane, modificato record DNS autoritativi e ottenuto certificati HTTPS validi per domini Google e YouTube. Il punto critico è proprio questo: non serviva entrare nei sistemi Google né compromettere direttamente una Certification Authority. Bastava controllare temporaneamente la zona DNS per apparire, agli occhi del processo di validazione, come il legittimo titolare del dominio.

I registri .gh, .sl e .as diventano il punto debole della catena

Il post ufficiale del Chrome Secure Web and Networking Team attribuisce l’incidente alla compromissione di terze parti responsabili dei namespace .gh, .sl e .as e chiarisce che i sistemi Google non sono stati violati. Gli attaccanti hanno alterato i record DNS autoritativi e ottenuto certificati HTTPS non autorizzati per proprietà Google e per domini appartenenti ad altre organizzazioni. Questo distingue il caso dal classico furto di account di un singolo registrar: qui il problema si colloca più in alto nella gerarchia, perché la compromissione di un’infrastruttura ccTLD può mettere a rischio molteplici domini sotto la stessa estensione nazionale. È lo stesso principio di concentrazione del rischio visto quando gli hacker hanno dirottato il DNS degli hotel per colpire account Microsoft 365, ma spostato dal singolo operatore alla struttura che governa un’intera porzione del namespace.

Leggi anche: BGP hijacking colpisce Virtualizor, Packagist diffonde spyware sugli iPhone

Il certificato è valido perché il DNS dice che l’attaccante è il proprietario

Il passaggio tecnico rende l’incidente più insidioso di un semplice redirect. Le Certification Authority rilasciano certificati Domain Validation dopo che il richiedente dimostra il controllo del dominio, per esempio pubblicando un valore specifico nel DNS. Se però l’aggressore controlla i record autoritativi, può completare legittimamente quella verifica dal punto di vista della CA. Google afferma infatti di non avere motivi per ritenere che le autorità di certificazione coinvolte abbiano agito in modo scorretto. Il certificato risultante è crittograficamente valido, ma viene emesso a chi ha ottenuto il controllo fraudolento del dominio. Il problema ricorda, su un altro livello della catena di fiducia, i casi nei quali certificati rubati sono stati utilizzati per firmare malware come Golden Gh0st RAT: la crittografia continua a funzionare, ma autentica un’identità o un artefatto che l’attaccante è riuscito a presentare come affidabile.

I Certificate Transparency log mostrano almeno dodici emissioni

L’ originale dei registri CT ha individuato almeno dodici certificati relativi a sette domini Google e YouTube, registrati tra il 22 e il 27 settembre. Undici sarebbero stati emessi da Let’s Encrypt e uno da ZeroSSL. Tra i nomi osservati compaiono google.com.gh, google.sl, google.as e domini YouTube collegati alle tre estensioni; tutti i certificati risultavano revocati al 7 ottobre. La finestra tra registrazione nei CT log e revoca è però variata da circa un giorno e mezzo a quasi una settimana. Questo è il motivo per cui Certificate Transparency diventa una difesa operativa e non un semplice meccanismo di audit: consente ai proprietari di individuare rapidamente emissioni che non hanno richiesto. L’evoluzione di Chrome verso HTTPS obbligatorio e controlli di sicurezza più aggressivi riduce alcuni rischi di trasporto, ma non risolve il problema quando il certificato presentato è formalmente valido.

Chrome può bloccare i certificati, ma non può riparare il DNS

Google ha reagito inserendo i certificati non autorizzati nei CRLSets di Chrome e coordinandosi con le CA per la revoca, estendendo il blocco anche a certificati sospetti riferiti ad altre organizzazioni emerse dall’analisi dei CT log. Per gli utenti Chrome non è richiesta alcuna azione specifica, ma la stessa Google avverte che l’intervento del browser non può essere considerato una protezione universale: potrebbe non coprire tutti i domini colpiti e non protegge allo stesso modo client, browser o applicazioni differenti. Il limite è strutturale. Il browser interviene a valle, quando DNS e processo di emissione hanno già prodotto una falsa attestazione di controllo. Sul fronte DNS, inoltre, la sicurezza resta composta da più livelli: le vulnerabilità recentemente emerse in BIND e Unbound hanno mostrato quanto DNSSEC e resolver restino componenti sensibili dell’infrastruttura, ma nessun singolo controllo elimina il rischio derivante dalla compromissione dell’autorità che gestisce la zona.

Continua con:

Android 17 cifra il Client Hello: ECH nasconde i domini agli osservatori di rete

Brave lancia i Container, Chrome si aggiorna e Mozilla blinda i certificati web

Monitoraggio CT e CAA diventano controlli obbligatori per i proprietari di domini

Google raccomanda ai proprietari di monitorare continuativamente i Certificate Transparency log per l’intero portafoglio di domini, inclusi quelli regionali e parcheggiati, e di pubblicare record CAA restrittivi che limitino le CA autorizzate all’emissione, possibilmente associando anche specifici account ACME. Il CAA non impedisce però l’emissione durante un hijack DNS attivo, perché chi controlla la zona può modificare anche quel record; diventa invece importante dopo il ripristino, impedendo che una validazione del controllo dominio già effettuata venga riutilizzata per ottenere nuovi certificati. Il caso dei tre ccTLD mostra quindi che la sicurezza HTTPS non coincide con il lucchetto del browser: dipende da registri, DNS autoritativi, CA, log pubblici, meccanismi di revoca e configurazioni del proprietario. Quando uno di questi livelli viene sottratto al controllo legittimo, l’attaccante può entrare nella catena di fiducia senza dover rompere la crittografia.