Un sottodominio può rimanere online anche quando il servizio a cui era collegato non esiste più.
A prima vista potrebbe sembrare semplicemente un record DNS dimenticato.
In determinate condizioni, però, questo tipo di configurazione può portare a una vulnerabilità conosciuta come Subdomain Takeover.
Il concetto è abbastanza semplice:
Un sottodominio continua a puntare verso una risorsa esterna che non è più controllata dall'organizzazione, e quella risorsa può essere reclamata da qualcun altro.
Non tutti i record DNS abbandonati sono vulnerabili a un takeover, ma quando le condizioni sono presenti l'impatto può essere significativo.
Partiamo da un esempio
Immaginiamo che un'azienda abbia:
blog.example.com
Il sottodominio viene utilizzato per un servizio ospitato su una piattaforma esterna:
blog.example.com
↓
CNAME
↓
example-blog.provider.com
Per qualche tempo tutto funziona normalmente.
Poi l'azienda decide di eliminare il progetto.
Il servizio esterno viene cancellato.
Ma il record DNS rimane:
blog.example.com
↓
example-blog.provider.com
A questo punto abbiamo quello che viene comunemente chiamato un dangling DNS record.
Che cosa significa "dangling"?
In questo contesto significa, in sostanza, che il record DNS continua a puntare verso una risorsa che non esiste più o non è più sotto il controllo previsto.
Il DNS potrebbe continuare a indicare una destinazione valida dal punto di vista sintattico.
Il problema è ciò che c'è dall'altra parte.
Per esempio:
blog.example.com
↓
CNAME
↓
servizio-esterno.example-provider.com
↓
Risorsa eliminata
A questo punto bisogna verificare se il provider permette a un altro soggetto di registrare o reclamare quella risorsa.
Se sì, il sottodominio potrebbe diventare controllabile da un soggetto non autorizzato.
OWASP descrive proprio questo scenario come una delle condizioni alla base dei subdomain takeover.
Come può succedere?
Uno scenario tipico è:
1. Creo un servizio cloud
↓
2. Creo un CNAME
↓
3. Il sottodominio funziona
↓
4. Elimino il servizio
↓
5. Dimentico il record DNS
↓
6. La risorsa può essere reclamata
Il problema nasce quindi spesso durante il decommissioning di un servizio.
Creare un'infrastruttura è generalmente più semplice che ricordarsi di eliminare tutti i riferimenti quando quella stessa infrastruttura viene dismessa.
Perché un takeover è diverso da un semplice sottodominio abbandonato?
Perché nel takeover non ci limitiamo ad avere un host che non funziona.
La situazione potenzialmente pericolosa è questa:
example.com
│
└── blog.example.com
│
└── risorsa esterna
│
└── non più controllata
Se un soggetto esterno riesce a reclamare quella risorsa, può arrivare a controllare ciò che viene servito attraverso:
blog.example.com
A quel punto il problema riguarda direttamente il dominio dell'organizzazione.
Quali conseguenze può avere?
L'impatto dipende molto da come è configurato il dominio e da come viene utilizzato il sottodominio.
Un takeover può permettere, in determinate condizioni, di:
- pubblicare contenuti sotto un dominio legittimo;
- creare pagine di phishing;
- sfruttare la fiducia associata al dominio;
- interferire con alcune policy di sicurezza;
- creare problemi a flussi OAuth o SSO;
- influire su cookie o altre configurazioni che considerano affidabili i sottodomini.
OWASP evidenzia che l'impatto può estendersi, in determinate configurazioni, anche a cookie, Content Security Policy e flussi OAuth/SSO.
Questo non significa che ogni takeover abbia automaticamente tutti questi effetti.
Il contesto tecnico è fondamentale.
Un esempio con una piattaforma cloud
Supponiamo di avere:
docs.example.com
che punta a un servizio esterno.
Il progetto viene eliminato, ma il DNS rimane configurato.
Un eventuale attaccante non controlla direttamente:
docs.example.com
solo perché il record DNS è rimasto.
Deve prima verificare se la risorsa esterna può essere reclamata e se il provider consente di associarla nuovamente.
Questa distinzione è importante.
Un dangling record è una condizione da verificare.
Un subdomain takeover è una situazione in cui quella condizione può essere effettivamente sfruttata.
Come si individua un possibile takeover?
Il primo passo è naturalmente scoprire i sottodomini.
Per esempio:
example.com
www.example.com
blog.example.com
old.example.com
staging.example.com
Successivamente bisogna analizzare i record DNS e, quando presente, identificare destinazioni esterne come:
CNAME
A quel punto è possibile verificare se la destinazione:
- esiste ancora;
- appartiene ancora all'organizzazione;
- risponde correttamente;
- presenta una configurazione compatibile con un takeover.
OWASP descrive un processo basato proprio su subdomain enumeration, verifica dei record DNS e fingerprinting delle risposte dei servizi.
Non basta vedere una pagina di errore
Questo è un punto importante.
Un risultato come:
404 Not Found
non significa automaticamente:
"Questo sottodominio è vulnerabile."
Una risposta di errore può avere moltissime cause.
La verifica deve considerare il provider, la destinazione DNS e il comportamento specifico del servizio.
Per questo gli strumenti automatici dovrebbero essere utilizzati come supporto all'analisi, non come sostituto della validazione.
Perché succede così spesso?
Il problema è spesso organizzativo.
Un progetto cloud può essere creato da un team.
Il DNS può essere gestito da un altro.
Il servizio può essere eliminato mesi dopo da una terza persona.
Se nessuno collega questi passaggi, può rimanere un record DNS orfano.
OWASP evidenzia proprio questa disconnessione tra provisioning delle risorse, gestione DNS e decommissioning come una delle cause ricorrenti del problema.
Come prevenire un Subdomain Takeover?
La prevenzione più efficace è molto semplice come concetto:
Quando elimini un servizio, elimina anche i riferimenti DNS che lo utilizzano.
Può essere utile inserire una checklist nel processo di decommissioning:
[ ] Servizio disattivato
[ ] Risorsa cloud eliminata
[ ] Record DNS rimosso
[ ] CNAME verificati
[ ] Certificati verificati
[ ] Redirect aggiornati
[ ] Documentazione aggiornata
[ ] Monitoraggio aggiornato
Inoltre, è utile mantenere un inventario dei sottodomini e monitorare periodicamente eventuali cambiamenti.
Anche i certificati possono fornire indizi
I certificati TLS e i log di Certificate Transparency possono aiutare a scoprire hostname associati a un'organizzazione.
Questo è utile anche nel contesto della sicurezza perché può far emergere:
dev.example.com
staging.example.com
old.example.com
che magari non erano presenti nell'inventario iniziale.
OWASP include proprio Certificate Transparency tra le fonti utili per l'attack surface discovery.
Cosa fare se trovi un possibile takeover?
Se sospetti un subdomain takeover, la prima cosa da fare è non considerarlo automaticamente confermato.
Verifica:
- il record DNS;
- la destinazione;
- il provider utilizzato;
- lo stato della risorsa;
- il comportamento della risposta;
- se la risorsa può realmente essere reclamata;
- quali applicazioni o servizi si fidano del sottodominio.
Se il takeover è confermato, la mitigazione più immediata è normalmente rimuovere o correggere il record DNS che mantiene il collegamento alla risorsa non controllata. OWASP indica la rimozione del record DNS come prima misura di contenimento.
Un problema piccolo che può avere conseguenze grandi
La cosa interessante del Subdomain Takeover è che spesso non nasce da una vulnerabilità sofisticata.
Può iniziare con:
un progetto eliminato
+
un record DNS dimenticato
La sicurezza dell'infrastruttura dipende quindi anche da attività apparentemente banali come mantenere aggiornati DNS e inventario degli asset.
Conclusione
Un sottodominio dimenticato non è necessariamente vulnerabile.
Ma quando un record DNS punta a una risorsa esterna che non è più sotto il controllo dell'organizzazione, vale la pena verificare attentamente la situazione.
Il Subdomain Takeover è un buon esempio di quanto sia importante conoscere non soltanto le vulnerabilità delle applicazioni, ma anche la relazione tra DNS, cloud e servizi esterni.
La prevenzione parte da una regola semplice:
Quando elimini un servizio, ricordati anche del DNS.
Controlla i tuoi sottodomini con MiHakero
MiHakero può aiutarti a individuare la superficie pubblica associata ai tuoi domini e a portare all'attenzione asset e configurazioni che meritano una verifica.
L'obiettivo è avere una visione più chiara di ciò che esiste realmente prima che un vecchio asset diventi un problema.