Come un dirottamento di un codice paese ha spezzato la catena di fiducia di Internet

Ricordo di essere stato seduto in un data center senza finestre nel 2011 quando scoppiò la notizia di DigiNotar. All'epoca, una singola autorità di certificazione compromessa nei Paesi Bassi permise agli aggressori di coniare credenziali fraudolente per Google. Sembrò un tradimento fondamentale della matematica che mantiene il web sicuro. Facciamo un salto in avanti fino alla fine del 2026, e il settore sta affrontando una versione dello stesso incubo, sebbene il punto di ingresso sia cambiato. Un apparato di sicurezza da miliardi di dollari è stato sconfitto dall'equivalente digitale di un fabbro che ruba le chiavi maestre da un ferramenta di una piccola città.

Google ha recentemente confermato che degli aggressori hanno dirottato tre domini di primo livello nazionali (ccTLD): .gh (Ghana), .sl (Sierra Leone) e .as (Samoa Americane). Ottenendo il controllo di questi namespace, gli attori hanno modificato i record DNS autorevoli per specifici bersagli di alto valore. Questo controllo ha permesso loro di aggirare i controlli di validazione automatizzati che le autorità di certificazione utilizzano per verificare la proprietà. Il risultato è stato l'emissione di certificati TLS non autorizzati per diversi domini Google e altri importanti marchi globali. Questo è il paradosso architettonico della sicurezza moderna: un'azienda può spendere milioni in zero trust e chiavi di sicurezza hardware, eppure la sua identità digitale rimane legata alla sicurezza amministrativa di un registro distante.

La meccanica del bypass del controllo del dominio

Per capire perché sia successo, dobbiamo guardare a come un sito web dimostra chi è. Quando un'organizzazione richiede un certificato TLS, l'Autorità di Certificazione (CA) emittente deve verificare che il richiedente controlli effettivamente il dominio. Lo standard del settore per questo è la Domain Control Validation (DCV). La CA chiede al richiedente di eseguire un compito specifico, come ospitare un file unico a un URL specifico o, più comunemente, creare uno specifico record DNS. Se la CA vede il record corretto sui nameserver autorevoli, emette il certificato.

In questo incidente, gli aggressori non hanno avuto bisogno di hackerare Google. Hanno hackerato l'infrastruttura TLD stessa. Una volta controllati i nameserver per .gh, .sl e .as, hanno puntato i record DNS per i sottodomini mirati ai propri server. Quando la CA ha eseguito il controllo automatizzato, il server degli aggressori ha fornito la risposta corretta. La CA ha seguito perfettamente il suo protocollo, ma stava parlando con un impostore. Il sistema è una cassaforte digitale che funziona solo se il buttafuori alla porta sa davvero che aspetto ha il vero proprietario.

Perché i blocchi dei browser sono una soluzione temporanea

Google ha aggiornato Chrome per bloccare immediatamente questi certificati non autorizzati. Si tratta di una misura reattiva che protegge milioni di utenti, ma evidenzia una debolezza sistemica. Il processo di revoca di un certificato è notoriamente lento. I metodi tradizionali come le Certificate Revocation Lists (CRL) o l'Online Certificate Status Protocol (OCSP) spesso falliscono a causa di problemi di privacy o latenza di rete. Di conseguenza, i produttori di browser si sono orientati verso blocklist codificate per fornire una protezione immediata.

Dal punto di vista del rischio, questo intervento è un cerotto. Google ha ammesso che gli interventi di Chrome non proteggono gli utenti su altri browser, né l'azienda può essere certa di aver identificato ogni dominio interessato. Se un aggressore possiede un certificato validamente firmato che un browser non ha ancora bloccato, può eseguire un attacco man-in-the-middle. Può intercettare il traffico, decrittografare dati sensibili e presentare un'icona a forma di lucchetto "sicuro" alla vittima. L'integrità della connessione è svanita e l'utente non ha modo di notare la differenza.

La materia oscura della rete aziendale

Il DNS è spesso la materia oscura della sicurezza aziendale. È invisibile, pervasivo e spesso trascurato finché qualcosa non si rompe. Molte organizzazioni trattano i loro rapporti con i TLD come una semplice questione di fatturazione piuttosto che come una dipendenza di sicurezza critica per la missione. Quando registri un dominio in un TLD nazionale, riponi la tua fiducia nella sicurezza del registro di quella nazione, nella stabilità del suo governo e nella sua resilienza tecnica.

Guardando al panorama delle minacce, questo incidente dimostra che gli aggressori si stanno spostando verso l'alto nella catena di approvvigionamento. Invece di attaccare un perimetro blindato, stanno prendendo di mira i componenti decentralizzati dell'infrastruttura centrale di Internet. Una violazione a livello di TLD è furtiva perché non fa scattare allarmi interni. I server dell'organizzazione sono a posto, i dipendenti non cliccano su link di phishing e il firewall è silenzioso. Eppure, l'identità del marchio viene contraffatta altrove.

Implementazione della Certification Authority Authorization

Google consiglia ai proprietari di domini di pubblicare record DNS di Certification Authority Authorization (CAA) come contromisura. Un record CAA è una dichiarazione di policy che comunica al mondo quali specifiche CA sono autorizzate a emettere certificati per un dominio. Se un attore malintenzionato cerca di ottenere un certificato dalla CA "A", ma il record CAA elenca solo la CA "B", la richiesta dovrebbe essere negata.

Tuttavia, i record CAA sono efficaci solo se sono restrittivi e se le CA li onorano. Cosa ancora più importante, se un aggressore dirotta il DNS, può semplicemente eliminare o modificare il record CAA prima di richiedere il certificato fraudolento. Google suggerisce che questi record possono impedire agli aggressori di riutilizzare i dati di validazione memorizzati nella cache, ma non sono una soluzione magica. Sono uno strumento granulare che aggiunge uno strato di attrito per l'aggressore, ma si affidano comunque all'integrità del DNS stesso.

L'importanza dei log di Certificate Transparency

Dietro le quinte, il modo più efficace per individuare questo tipo di attività è attraverso i log di Certificate Transparency (CT). Il CT è un sistema di log pubblici, di sola aggiunta, che registrano ogni certificato TLS emesso dalle CA partecipanti. Ogni volta che un certificato viene coniato per il tuo dominio, appare in questi log.

Parlando proattivamente, ogni team di sicurezza dovrebbe monitorare questi log per i propri domini. Se appare un certificato da una CA che non utilizzi, o in un momento in cui non ne hai richiesto uno, probabilmente sei di fronte a un dirottamento in corso. Utilizzo diversi strumenti automatizzati che mi avvisano via Signal nel momento in cui viene emesso un nuovo certificato per qualsiasi proprietà che gestisco. Questa visibilità forense è l'unico modo per rilevare un dirottamento a livello di TLD prima che si traduca in una massiccia violazione dei dati.

Lezioni dall'era DigiNotar

Questo incidente ci ricorda che il sistema dei certificati presenta difetti sistemici. Nel 2011, la violazione di DigiNotar è stata una situazione di ostaggio digitale per il popolo iraniano, il cui traffico è stato intercettato dal governo utilizzando certificati contraffatti. Mentre l'attuale dirottamento dei TLD sembra concentrato su marchi e servizi, la vulnerabilità tecnica è identica. Stiamo ancora utilizzando un modello di fiducia centralizzato in un mondo decentralizzato.

La crittografia è una cassaforte digitale infrangibile solo se le chiavi sono gestite con assoluta integrità. Quando l'infrastruttura che convalida quelle chiavi è compromessa, la porta della cassaforte viene lasciata spalancata. Gli aggressori in questo caso hanno dimostrato che non è necessario rompere la crittografia per vincere. Devi solo convincere il sistema che sei il legittimo proprietario della cassaforte.

Consigli pratici per i leader della sicurezza

La sicurezza riguarda spesso la gestione di dipendenze che non controlli. Sebbene non sia possibile proteggere l'infrastruttura di un registro TLD straniero, puoi controllare come la tua organizzazione risponde a questi rischi.

• Controlla il tuo portafoglio domini e identifica quali domini sono registrati sotto ccTLD con protocolli di sicurezza meno rigorosi.
• Pubblica record CAA per tutti i domini critici per limitare quali autorità possono emettere credenziali.
• Imposta il monitoraggio in tempo reale dei log di Certificate Transparency per intercettare emissioni non autorizzate in pochi minuti.
• Abilita le DNS Security Extensions (DNSSEC) dove possibile per aggiungere firme crittografiche ai tuoi dati DNS, rendendo i dirottamenti più difficili da eseguire.
• Rivedi il tuo piano di risposta agli incidenti per includere un protocollo per la revoca rapida dei certificati e il coordinamento con i fornitori di browser.

Come contromisura, questi passaggi assicurano che, anche se il registro TLD fallisce, il tuo team abbia la visibilità necessaria per reagire prima che il danno diventi sistemico. L'obiettivo è passare da una postura reattiva a una resiliente. La sicurezza non è uno stato che si raggiunge, ma un processo che si mantiene.

Fonti:

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Dichiarazione di non responsabilità: Questo articolo è solo a scopo informativo ed educativo e non sostituisce un audit professionale di cybersecurity o un servizio di risposta agli incidenti.