Un sito viene migrato.
Un servizio cloud viene dismesso.
Un ambiente di test viene eliminato.
Un progetto viene abbandonato.
Eppure, mesi dopo, il relativo record DNS può essere ancora lì.
È una situazione molto più comune di quanto si possa pensare.
Il problema è che un record DNS apparentemente innocuo può continuare a pubblicare informazioni sull'infrastruttura oppure puntare verso una risorsa che non viene più controllata.
Quando un record diventa "dimenticato"?
Immaginiamo di avere:
dev.example.com
che durante lo sviluppo puntava a:
dev-example.provider.com
Dopo la conclusione del progetto, il server o il servizio presso il provider viene eliminato.
Il record DNS, però, rimane:
dev.example.com → dev-example.provider.com
Dal punto di vista DNS la configurazione può continuare a essere perfettamente valida.
Il problema è che la destinazione non viene più necessariamente gestita dal proprietario del dominio.
Questa è una delle situazioni che meritano maggiore attenzione.
Il problema dei CNAME verso servizi esterni
I record CNAME sono particolarmente interessanti perché vengono spesso utilizzati per integrare piattaforme di terze parti.
Per esempio:
support.example.com → example.zendesk.com
oppure:
status.example.com → customer-status.provider.com
oppure ancora:
blog.example.com → account.hosting-platform.com
Se il servizio viene rimosso ma il CNAME resta, il sottodominio continua a puntare verso quella destinazione.
Non significa automaticamente che esista una vulnerabilità.
Significa però che il record dovrebbe essere verificato.
Un record DNS non utilizzato è sempre un problema?
No.
Un record DNS inutilizzato non equivale automaticamente a una vulnerabilità.
Potrebbe essere:
- intenzionale;
- utilizzato solo occasionalmente;
- mantenuto per compatibilità;
- destinato a un servizio che verrà riattivato;
- semplicemente configurato in modo particolare.
La sicurezza richiede quindi di distinguere tra:
"questo record esiste"
e:
"questo record rappresenta un rischio concreto".
Questa distinzione è importante anche quando si utilizzano strumenti automatici di sicurezza.
Subdomain takeover
Uno dei rischi più conosciuti associati ai record DNS abbandonati è il subdomain takeover.
Lo scenario generale è questo:
blog.example.com
↓
servizio esterno
↓
risorsa eliminata
Il record DNS rimane attivo, ma la risorsa associata non è più sotto il controllo del proprietario del dominio.
In determinate condizioni, un'altra persona potrebbe riuscire a registrare o reclamare quella risorsa presso il provider.
A quel punto il sottodominio legittimo:
blog.example.com
potrebbe iniziare a puntare verso un contenuto controllato da terzi.
È uno scenario serio, ma non tutti i CNAME "orfani" sono automaticamente sfruttabili.
La possibilità concreta dipende dal provider, dal servizio utilizzato e dallo stato della risorsa.
I record possono anche rivelare informazioni
Anche quando non esiste un takeover, un vecchio record può fornire informazioni utili.
Per esempio:
dev.example.com
staging.example.com
old.example.com
vpn-old.example.com
backup.example.com
possono rivelare l'esistenza passata o attuale di componenti dell'infrastruttura.
Non significa che siano vulnerabili.
Ma sono informazioni che possono essere utilizzate per comprendere meglio la superficie pubblica dell'organizzazione.
Il problema delle migrazioni
Le migrazioni sono uno dei momenti in cui è più facile accumulare configurazioni obsolete.
Un'organizzazione passa:
Provider A
↓
Provider B
e modifica il record principale:
www.example.com
Ma magari rimangono:
old.example.com
api-old.example.com
staging.example.com
legacy.example.com
Questi record possono essere dimenticati perché non sono coinvolti nel normale funzionamento del sito.
Anche i record MX meritano attenzione
Il concetto non riguarda soltanto i siti web.
Anche la posta elettronica può avere configurazioni obsolete.
Per esempio:
example.com
MX → old-mail.example.net
Se quel server non viene più utilizzato, bisogna capire perché il record è ancora presente.
Un'infrastruttura DNS ordinata dovrebbe riflettere lo stato reale dei servizi.
Come fare un controllo periodico
Un inventario DNS dovrebbe permettere di rispondere a domande molto semplici:
- Quali sottodomini abbiamo?
- A cosa puntano?
- Quali servizi sono gestiti internamente?
- Quali dipendono da provider esterni?
- Quali record sono stati creati per ambienti di test?
- Quali record appartengono a vecchi progetti?
- Esistono destinazioni che non riconosciamo più?
- Ci sono CNAME verso servizi che non utilizziamo?
Un controllo può iniziare anche con una semplice interrogazione DNS:
dig example.com
Per un sottodominio:
dig blog.example.com
E per ottenere informazioni più specifiche:
dig CNAME blog.example.com
Questi comandi non dimostrano la presenza di una vulnerabilità.
Servono principalmente a capire cosa viene pubblicato dal DNS.
Una buona pratica: mantenere un inventario
Una soluzione semplice è mantenere una tabella interna:
| Record | Tipo | Destinazione | Utilizzato | Proprietario | | ------ | ----- | ----------------- | ---------- | ------------ | | www | A | Server web | Sì | IT | | api | A | Server API | Sì | Dev | | blog | CNAME | Provider esterno | Sì | Marketing | | old | CNAME | Servizio dismesso | No | — |
La colonna più importante è spesso proprio quella apparentemente banale:
Chi è responsabile di questo record?
Se nessuno sa rispondere, vale la pena approfondire.
In sintesi
Un record DNS dimenticato non è necessariamente una vulnerabilità.
È però un possibile indicatore di una superficie di attacco non più mantenuta.
I casi più interessanti sono quelli in cui un record:
- punta verso un servizio esterno;
- appartiene a un ambiente dismesso;
- utilizza una destinazione non più riconosciuta;
- espone un vecchio componente dell'infrastruttura;
- può essere associato a un servizio che non è più sotto il controllo dell'organizzazione.
La gestione della superficie di attacco non termina quando viene pubblicato un sito.
Bisogna anche sapere cosa continua a essere pubblicato nel tempo.
MiHakero può aiutare a mantenere sotto osservazione ciò che è visibile dall'esterno e a evidenziare elementi che meritano una verifica.