Gli aggressori hanno compromesso operatori terzi legati ai ccTLD .gh, .sl e .as, modificato i record DNS autorevoli e ottenuto certificati HTTPS non autorizzati per domini Google e YouTube.
Google ha dichiarato che l’incidente non ha comportato una violazione dei propri sistemi. Ha inoltre affermato di non avere motivo di ritenere che le autorità di certificazione che hanno rilasciato i certificati abbiano agito in modo scorretto.
Google non ha indicato la data dei dirottamenti. Ha scoperto l’attività nella settimana precedente al post del 6 ottobre e ha dichiarato di essere intervenuta immediatamente. La notizia è stata riportata il 7 ottobre 2026.
Una verifica dei log di Certificate Transparency condotta da The Hacker News ha individuato almeno dodici certificati con convalida del dominio, validi per sette domini Google e YouTube. I certificati sono comparsi per la prima volta nei log pubblici il 22, il 25 e il 27 settembre.
Le prove disponibili confermano il rilascio non autorizzato, ma non dimostrano che gli utenti siano stati presi di mira. Né Google né la verifica dei certificati hanno accertato che gli aggressori li abbiano usati per impersonare un sito web, intercettare il traffico o raccogliere informazioni.
Le modifiche al DNS autorevole hanno preceduto il rilascio dei certificati
Le autorità di certificazione rilasciano certificati con convalida del dominio dopo aver verificato che il richiedente controlli il dominio indicato. La convalida basata sul DNS è uno dei metodi possibili, ma le informazioni disponibili non chiariscono esattamente come siano stati effettuati i controlli in questo caso.
È invece accertato che gli aggressori hanno modificato i record DNS autorevoli dopo aver compromesso operatori terzi legati ai tre ccTLD. Le modifiche hanno indirizzato i domini interessati verso infrastrutture controllate dagli aggressori; in seguito sono stati rilasciati certificati non autorizzati per domini Google e YouTube.
Un certificato valido potrebbe consentire a una destinazione controllata dagli aggressori di stabilire una connessione cifrata per il dominio in questione, senza il consueto avviso di mancata corrispondenza del certificato. L’operatore potrebbe quindi mostrare contenuti arbitrari, compresa una copia convincente del sito legittimo.
Si tratta di un impatto potenziale, non di un esito confermato. Le fonti non dimostrano che i certificati siano stati usati per impersonare Google o YouTube, né che siano stati esposti dati privati.
Google non ha identificato gli aggressori né spiegato in che modo abbiano compromesso gli operatori terzi. Non ha neppure dichiarato se i domini interessati siano stati messi in sicurezza.
Il rischio non riguardava necessariamente solo Google. Secondo l’azienda, i dati di Certificate Transparency hanno rivelato certificati apparentemente collegati agli stessi attacchi e relativi a organizzazioni che si ritiene siano state coinvolte, tra cui importanti marchi globali e servizi online molto diffusi. Google non li ha nominati.
Questa dichiarazione non significa che siano stati compromessi tutti i domini sotto .gh, .sl o .as.
I log pubblici hanno rivelato almeno dodici certificati
Il 7 ottobre The Hacker News ha effettuato ricerche su ctlogs.dev e Cert Spotter. La verifica, circoscritta, ha individuato dodici certificati per youtube.com.gh, google.com.gh, google.sl, google.com.sl, youtube.sl, google.as e youtube.as, comprese voci wildcard e www.
Let’s Encrypt ha rilasciato undici certificati, mentre ZeroSSL ne ha rilasciato uno. Il 7 ottobre Matthew McPherrin, membro dello staff di Let’s Encrypt, ha confermato sul forum della community dell’autorità di certificazione che erano stati rilasciati e revocati certificati per Google e YouTube.
| Nomi indicati nel certificato | Autorità emittente | Primo inserimento nei log | Revoca |
|---|---|---|---|
*.youtube.com.gh, youtube.com.gh |
Let’s Encrypt | 22 settembre, 11:03 | 26 settembre, 02:41 |
*.google.com.gh, google.com.gh |
Let’s Encrypt | 22 settembre, 11:59 | 26 settembre, 02:41 |
*.google.sl, google.sl |
Let’s Encrypt | 25 settembre, 04:36 | 1 ottobre, 19:36 |
google.sl, www.google.sl |
Let’s Encrypt | 25 settembre, 04:36 | 1 ottobre, 19:36 |
google.com.sl, www.google.com.sl |
ZeroSSL | 25 settembre, 04:51 | 26 settembre, 14:56 |
*.google.com.sl, google.com.sl |
Let’s Encrypt | 25 settembre, 04:51 | 1 ottobre, 19:36 |
www.youtube.sl, youtube.sl |
Let’s Encrypt | 25 settembre, 06:06 | 1 ottobre, 19:36 |
*.youtube.sl, youtube.sl |
Let’s Encrypt | 25 settembre, 06:07 | 1 ottobre, 19:36 |
google.as, www.google.as |
Let’s Encrypt | 27 settembre, 03:33 | 1 ottobre, 19:18 |
*.google.as, google.as |
Let’s Encrypt | 27 settembre, 03:43 | 1 ottobre, 19:18 |
google.as, www.google.as |
Let’s Encrypt | 27 settembre, 04:17 | 1 ottobre, 19:18 |
*.youtube.as, youtube.as |
Let’s Encrypt | 27 settembre, 04:37 | 1 ottobre, 19:18 |
Per questi orari non è stato specificato il fuso orario. Il 7 ottobre Cert Spotter indicava come revocati tutti e dodici i certificati.
I record esaminati risalivano almeno al 10 settembre. Per google.com.gh, google.sl e google.as, tutti gli altri certificati individuati in quei record erano stati rilasciati da Google Trust Services, l’autorità di certificazione di Google.
La ricerca ha riguardato solo una selezione limitata di domini Google e YouTube. Il totale di dodici indica quindi i certificati individuati in quella verifica, non l’entità complessiva dell’incidente.
Google ha usato il sistema di blocco d’emergenza di Chrome
Google ha dichiarato di aver bloccato i certificati non autorizzati relativi ai propri servizi tramite CRLSets, il meccanismo di Chrome che consente di rifiutare rapidamente certificati revocati o non attendibili. L’azienda ha inoltre collaborato con le autorità emittenti per revocare i certificati, estendendo così la risposta agli altri browser e alle applicazioni che elaborano le relative informazioni di revoca.
Dopo aver esaminato i log di Certificate Transparency, Google ha bloccato altri certificati apparentemente collegati agli attacchi. Ove possibile, ha contattato le organizzazioni che riteneva coinvolte.
Google ha dichiarato che gli utenti di Chrome non devono fare nulla. Ha tuttavia avvertito che l’analisi potrebbe non aver individuato tutti i domini interessati e che gli interventi di Chrome non proteggono in modo affidabile gli utenti di altri browser.
La revoca limita l’ulteriore utilizzo dei certificati nei client che ricevono e applicano lo stato aggiornato. Non chiarisce se qualche certificato sia stato usato prima della revoca.
Non sono stati comunicati né il numero di utenti interessati né il totale delle vittime confermate.
Le impronte dei certificati possono aiutare le verifiche difensive
I team di sicurezza possono usare le seguenti impronte SHA-256 per individuare i dodici certificati segnalati nei servizi di Certificate Transparency, negli inventari dei certificati o nei dati di telemetria pertinenti. L’ordine corrisponde alla tabella precedente.
0357032e1214ae11d7da8e00f6b89fb7694e240b17d05f2f47feaf43e96aa7d8
8886ca2b71501a6729f1ae868bd7d7b9b53c5cb6b5c7d851d041db4d6206945d
986d36b1c68c3e800596c4680dd6c67c42118955e08b472f641793c59dcd347b
2e1f6d7f24650b0720636efe48f2ccf59704ee6f11ffa52b5a4c4afcc474fe91
e1667fe4e4ea98427960ea2eda7c53af1246ec58ac22282a6877d394a0957065
e1e4fd74f673f1df9c039ae6424b36868a0475a043abea2dedd1f6f12a365ebf
5b7c491c8784eb438b1634981f1ea6333d3557431268233c2a7a92173ca17122
a10d3b5dbc142d040e6ae772ab41dc44b0e94659237709d1241fdefdd36f7b35
491f453d208bbb7923626c208df93c95fdfae3b78b738b996c8dafda9d00619a
798079c762496d26ce99d3a9113cb24715e31ec8a69a6cdcffa70f5001e19df0
607afd2745b84c4332e028262937be35f25316aadf584340269d23a3dbcd37ef
b7ea8c77695cf9791a9d45f17c33ebb9bd5f68d4c96df6f56136dc6a834576d2
Una corrispondenza identifica uno dei certificati individuati nella verifica. Non dimostra che un utente si sia collegato a un sito contraffatto o che le sue informazioni siano state intercettate.
I titolari dei domini dovrebbero controllare i domini regionali e parcheggiati
Google ha raccomandato di monitorare i log di Certificate Transparency per l’intero portafoglio di domini, compresi quelli parcheggiati e le registrazioni regionali sotto ccTLD. I titolari di domini sotto .gh, .sl o .as dovrebbero controllare le voci recenti e verificare che i certificati indicati siano stati effettivamente richiesti.
È possibile segnalare alla CA emittente un certificato non richiesto tramite un Certificate Problem Report. In base ai CA Baseline Requirements, la CA deve indagare e fornire i primi riscontri entro 24 ore.
Google ha inoltre raccomandato di adottare record Certification Authority Authorization restrittivi. CAA può limitare il rilascio ai soli CA approvati e, se supportato, agli account ACME e ai metodi di convalida autorizzati.
Durante un dirottamento attivo del DNS autorevole, CAA non può impedire il rilascio se l’aggressore è in grado di rimuovere o falsificare il record. La protezione diventa rilevante una volta ripristinato il controllo legittimo del DNS, perché una CA potrebbe riutilizzare una precedente convalida del dominio andata a buon fine per richieste successive.
Google ha dichiarato che una policy CAA restrittiva può impedire ulteriori rilasci basati su quella convalida memorizzata nella cache. Il 7 ottobre Google Public DNS restituiva record CAA per tutti e sette i domini individuati, che autorizzavano solo pki.goog, il dominio di Google Trust Services. Le informazioni disponibili non chiariscono quando siano stati aggiunti questi record.
In base alla pianificazione approvata dal CA/Browser Forum nell’aprile 2025, il periodo massimo di riutilizzo della convalida resta di 200 giorni. Scenderà a 100 giorni nel marzo 2027 e a 10 giorni nel marzo 2029. A dicembre 2025 Let’s Encrypt ha dichiarato di riutilizzare una verifica del dominio per 30 giorni e di voler ridurre tale periodo a sette ore entro il 2028.
