DNS pendenti: come trovarli e correggerli prima di un takeover

I DNS pendenti sono uno di quei problemi facili da creare e genuinamente difficili da individuare. Un record continua a puntare a una risorsa cloud dopo che la risorsa non esiste più, e a meno che qualcosa non lo tenga sotto controllo, nessuno se ne accorge finché non diventa un problema. La buona notizia è che non devi elaborare tutto da zero. Due tra le fonti più autorevoli nel settore della sicurezza, OWASP e AWS, documentano perché si verificano i DNS pendenti e cosa fare al riguardo. Questo blog copre il rischio, cosa dice ciascuno di loro, come mettere in pratica le loro indicazioni e dove si trovano le lacune degli strumenti che lasciano la maggior parte dei team esposta.

Riepilogo esecutivo: I record DNS pendenti permettono agli attaccanti di impossessarsi di un sottodominio senza violare nulla. OWASP e AWS documentano entrambi il problema e la soluzione, e le linee guida aggiornate del NIST ora lo nominano direttamente. La correzione è semplice per singolo record. La parte difficile è trovare i record pendenti in modo continuo in un estate reale con più registrar e cloud, ed è proprio questa la lacuna che Red Sift può colmare.

Punti chiave:

• Un record DNS pendente punta a una risorsa cloud che è stata eliminata. Se il nome della risorsa può essere riutilizzato, un attaccante può servire i propri contenuti sul tuo sottodominio.
• Non è segno di un team disattento. È un effetto collaterale strutturale della rapidità con cui le risorse cloud vengono create e dismesse.
• Sia OWASP che AWS documentano il problema, quindi esistono indicazioni chiare e autorevoli da seguire.
• AWS è schietta sul fatto che la sua piattaforma non colma la lacuna per te: nomi di risorse riutilizzabili, nessuna verifica universale del dominio, e attaccanti che già scansionano alla ricerca di record pendenti.
• La correzione è semplice per singolo record. La parte difficile è la scoperta continua in un estate multi-registrar e multi-cloud, dove Red Sift Attack Surface Management fa la differenza.

Un record DNS pendente è una voce DNS, solitamente un CNAME (Canonical Name, che associa un nome a un altro), che continua a puntare a una risorsa cloud dopo che quella risorsa è stata eliminata. Il servizio non c'è più. Il record sì. Su molte piattaforme cloud, il nome della risorsa torna quindi in un pool condiviso che qualsiasi cliente può rivendicare. Un attaccante che ricrea una risorsa con quel nome eredita il tuo sottodominio, perché il tuo DNS sta ancora inviando traffico lì.

Nessuna violazione, nessuna password rubata. Il record semplicemente sopravvive alla risorsa, e il vuoto che lascia è rivendicabile.

Il motivo per cui questo conta più di una semplice pagina non funzionante è la fiducia che il tuo dominio già porta con sé. Un sottodominio che i tuoi clienti, i browser e i sistemi di posta trattano come tuo diventa controllato dall'attaccante. Questo apre la strada a phishing su un dominio riconosciuto dalle persone, furto di cookie di sessione con ambito sul dominio principale, dirottamento dei flussi di login OAuth e SSO, e certificati TLS validi rilasciati a tuo nome tramite i controlli di convalida del dominio. Se la catena di record coinvolge la posta, può significare anche l'intercettazione dei reset delle password. Questa è la modalità di guasto "presa in ostaggio".

OWASP, la comunità di standard neutrale rispetto ai fornitori, tratta il subdomain takeover come un problema operativo piuttosto che un bug software, e il suo punto più utile è anche il più semplice. La maggior parte delle organizzazioni non ha modo di rilevare quando il target di un record DNS smette silenziosamente di esistere. Questo è lo stato predefinito, non un fallimento della diligenza. Il record e la risorsa si allontanano, nulla li riconcilia, e il vuoto rimane aperto finché qualcuno non ci inciampa.

Le indicazioni di prevenzione di OWASP sono chiare e pratiche: mantieni un inventario di ciò a cui puntano i tuoi record, rimuovi i record prima delle risorse da cui dipendono, e monitora le stringhe di errore del provider che una risorsa morta restituisce prima che qualcuno la rivendichi. È un buon consiglio pratico, ed è gratuito.

AWS documenta questo nelle proprie linee guida sulla sicurezza, e la franchezza merita un riconoscimento. È esplicita nel dire che la piattaforma non colma questa lacuna per te, e ne indica tre motivi:

• Molti servizi AWS permettono a un nuovo cliente di rivendicare un hostname o un nome di risorsa precedentemente utilizzato.
• AWS attualmente non offre un meccanismo di verifica universale del dominio su tutti i suoi servizi.
• I team di risposta agli incidenti di AWS osservano attaccanti che scansionano attivamente il DNS pubblico alla ricerca di record CNAME che puntano a risorse non più esistenti.

Quest'ultimo punto conta. Non è un rischio teorico in attesa in un backlog. È un comportamento di scansione attivo, in corso ora.

Ecco la distinzione utile tra le due voci. OWASP non è AWS, quindi può consigliare ma non può cambiare il funzionamento del cloud. AWS potrebbe aggiungere controlli universali, come la verifica del dominio che neutralizzerebbe la maggior parte di questo problema, ma finora non ha scelto di farlo. Questo lascia un vero divario tra ciò che i provider ti forniscono e ciò di cui hai bisogno per rimanere protetto. Non è un divario che hai creato tu, e colmarlo non richiede di aspettare che un provider agisca. Richiede visibilità, e la visibilità è qualcosa che puoi aggiungere oggi stesso.

Seguire questo consiglio per un record a cui stai attivamente pensando è facile. Applicarlo in un estate che non riesci a vedere completamente è la parte difficile. Il cloud ha cambiato a cosa serve il DNS, e gli estate sono cresciuti di conseguenza. In un'azienda reale, un singolo dominio apice ha rivelato oltre 25.000 sottodomini, con la proprietà distribuita tra infrastruttura, marketing, sviluppatori, fornitori SaaS e provider cloud. Nessun singolo team può vedere tutto questo manualmente.

Quindi la risposta non è una pulizia una tantum. È un modello operativo ripetibile. Queste cinque fasi, allineate ai temi NIST, trasformano le indicazioni in qualcosa che puoi effettivamente gestire.

1. Inventario. Scopri ogni dominio, ogni zona, ogni record, indipendentemente da chi lo gestisce: più registrar, più provider DNS, multi-cloud e più autorità di certificazione. Non puoi proteggere ciò che non hai trovato.
2. Baseline. Caratterizza come appare il "buono": i registrar e i provider DNS che approvi, i range cloud e le autorità di certificazione approvati, la tua postura di autenticazione email, e dove firmi con DNSSEC. Senza una baseline, ogni cambiamento sembra uguale e nulla appare sospetto.
3. Rileva e classifica. Fai emergere i cambiamenti inaspettati e sopprimi il rumore atteso. Circa l'1% dei nomi cambia ogni giorno, il che corrisponde a circa 375 eventi al giorno. La classificazione è l'unica cosa che rende questo gestibile.
4. Valuta continuamente. Esegui l'estate rispetto ai temi NIST SP 800-81r3: protezione del servizio DNS, minacce di trasferimento di zona, contenuto e coerenza della zona, minimizzazione della fuga di informazioni, integrità del dominio esterno, e firma e validazione DNSSEC.
5. Assegna priorità. Suddividi l'estate in livelli in modo che il modello rimanga sostenibile. Non tutto richiede la stessa attenzione.

Fai questo e il consiglio di inventario di OWASP e il consiglio di AWS "rimuovi il record prima della risorsa" smettono di essere aspirazioni. Diventano passaggi che puoi misurare e ripetere.

La fase che mette in difficoltà tutti è la prima, perché non puoi inventariare o monitorare ciò che non riesci a vedere, e né i provider né gli strumenti gratuiti ti offrono una visione completa. I controlli di configurazione nativi del cloud sono utili ma sono progettati per un singolo account e un singolo cloud. Gli scanner open source coprono più terreno ma vengono eseguiti solo quando ti ricordi di eseguirli. I record che vengono presi in ostaggio sono raramente quelli a cui stai pensando. Sono quelli che hai dimenticato, ereditato in un'acquisizione, o di cui non conoscevi nemmeno l'esistenza.

Red Sift ASM (Attack Surface Management) copre le lacune che le piattaforme lasciano aperte. Scopre domini e sottodomini in tutta la tua superficie esterna, ispeziona le configurazioni DNS, web e cloud, e segnala i record pendenti e le risorse rivendicabili non appena appaiono, su ogni registrar e cloud anziché un account alla volta. In pratica, ti offre lo strato di verifica continua che AWS non fornisce, applicato all'intero tuo estate.

Una buona igiene DNS, rimuovere il record prima della risorsa, è la prima linea di difesa, e sia OWASP che AWS ti forniscono un solido manuale operativo per questo. La scoperta continua è ciò che cattura i record che comunque sfuggono. Non devi aspettare che un provider colmi la lacuna per anticiparla.

Scopri a cosa punta il tuo DNS con Red Sift ASM o consulta l'intera raccolta di guide Red Sift per saperne di più sulla gestione del rischio DNS e dei certificati.