Gli hijack DNS che hanno coinvolto i namespace .gh, .sl e .as ricordano una cosa semplice, ma spesso sottovalutata: la fiducia del web non nasce solo dal certificato HTTPS visibile nel browser. Nasce prima, nella catena operativa che permette a un dominio di dimostrare di essere davvero sotto il controllo del suo titolare.
CircleID ha riportato che l’analisi dei log pubblici di Certificate Transparency ha individuato 32 certificati HTTPS non autorizzati emessi durante attacchi ai ccTLD di Ghana, Sierra Leone e Samoa americane. Google, in una disclosure tecnica del team Chrome Secure Web and Networking, ha confermato che gli attaccanti hanno modificato record DNS autorevoli e ottenuto certificati per domini Google e per domini di altre organizzazioni.
Leggi anche: ICANN misura i domini associati: il DNS abuse lascia tracce anche nei dati pubblici
Quando il controllo DNS diventa controllo del certificato
Il punto tecnico è decisivo per chi gestisce domini, portfolio corporate o infrastrutture registry. Le Certification Authority verificano il controllo di un dominio prima di emettere un certificato. Se un attaccante riesce a controllare temporaneamente i record DNS usati per quella validazione, può far apparire legittima una richiesta che non lo è.
Secondo CircleID, i certificati individuati sarebbero stati emessi tra il 22 e il 27 settembre. L’ordine temporale citato dalla fonte vede prima il namespace .gh, poi .sl, infine .as. La stessa ricostruzione indica che molti certificati collegati a ciascun incidente sarebbero stati emessi in una finestra breve, intorno a novanta minuti.
Google ha precisato che gli incidenti non hanno comportato una compromissione dei propri sistemi e che non vi sono indicazioni di condotta impropria da parte delle CA coinvolte. Questo è un dettaglio importante: il problema non è necessariamente la CA che emette, ma il fatto che il processo di domain control validation si appoggia a segnali DNS che possono essere alterati se il livello registry o la delega vengono compromessi.
La risposta di Chrome e il limite della protezione browser
Chrome ha reagito bloccando i certificati non autorizzati tramite CRLSet e lavorando con le CA per la revoca. Google ha inoltre usato i log di Certificate Transparency per identificare altre organizzazioni potenzialmente impattate e ha esteso i blocchi dove necessario.
È una mitigazione utile, ma non basta come modello di difesa. Google stessa avverte che l’intervento lato browser non può garantire di aver individuato ogni dominio coinvolto e non protegge automaticamente tutti gli utenti, tutti i browser e tutte le applicazioni. Per Webinvest, questo è il passaggio che trasforma la notizia da incidente tecnico a tema operativo per chi possiede o gestisce domini.
Leggi anche: Verisign Informed e .pki: la fiducia dei certificati entra nel lessico dei domini
Cosa devono controllare domain owner, registry e registrar
La prima azione è monitorare i log CT su tutto il portafoglio, non solo sui domini principali. I domini parcheggiati, regionali, difensivi o acquisiti anni prima sono spesso quelli meno osservati, ma possono diventare superficie di attacco reputazionale se un certificato inatteso viene emesso su un nome controllato male.
La seconda azione riguarda i record CAA. Google raccomanda configurazioni restrittive, possibilmente con controlli legati ad account e metodi di validazione autorizzati. La CAA non risolve tutto durante un hijack DNS attivo, perché anche quel record può essere manipolato se l’attaccante controlla la zona. Però riduce il rischio di emissioni successive quando il controllo legittimo viene ripristinato e rende più disciplinata la relazione tra dominio, CA e processo di rilascio.
Per i registry ccTLD, l’episodio alza anche il livello delle aspettative pubbliche. Un ccTLD non è solo un suffisso locale: è un pezzo di infrastruttura di fiducia usato da aziende globali, enti pubblici, servizi cloud e brand internazionali. Se la catena autorevole viene alterata, l’effetto non resta confinato al mercato locale.
La lezione per il mercato dei domini
Per i domain investor il messaggio è meno immediato, ma concreto. Un nome con buona storia, traffico o valore commerciale perde forza se è associato a segnali tecnici opachi: certificati inattesi, DNS instabile, deleghe trascurate, record non documentati, vecchi domini regionali dimenticati. La due diligence non può fermarsi a Whois, prezzo e comparabili; deve includere anche cronologia DNS, CT log e postura di sicurezza.
Leggi anche: DNSSEC in Africa al 53%: il rollover KSK diventa un test per registry e resolver
Il tema riguarda anche i registrar. Se un cliente corporate gestisce decine o centinaia di estensioni nazionali, il registrar non vende soltanto rinnovi: vende controllo, alert, processo e capacità di escalation. In un incidente come questo, la differenza tra un dominio inventariato e un dominio dimenticato può diventare la differenza tra un falso positivo gestibile e una crisi di reputazione.
La lettura Webinvest
Questi hijack mostrano che DNS, certificati e reputazione del dominio sono ormai lo stesso piano operativo. Il lucchetto HTTPS non è un punto di arrivo indipendente: è il risultato di una catena che parte dalla delega, passa per i record autorevoli, tocca la validazione CA e arriva al browser.
Per chi investe, registra o gestisce domini, il valore non sta più solo nel nome breve, memorabile o commerciale. Sta anche nella capacità di dimostrare controllo continuo. Monitorare CT log, ridurre le CA autorizzate, documentare i domini difensivi e trattare i ccTLD come asset infrastrutturali diventa parte della gestione ordinaria. La sicurezza non aggiunge fascino a un dominio, ma può evitare che quel dominio perda fiducia proprio quando serve di più.
Fonte principale: CircleID. Approfondimento tecnico: Google Security Blog; ricostruzione CT: iTnews.
← Tutte le news