Quando un'azienda registra un dominio, spesso il sito principale è solo una piccola parte di quello che viene effettivamente pubblicato online.
Nel corso degli anni possono comparire sottodomini dedicati a progetti, applicazioni, API, ambienti di test, pannelli amministrativi o vecchi servizi.
Per esempio:
example.com
www.example.com
api.example.com
app.example.com
staging.example.com
dev.example.com
test.example.com
Il problema non è avere molti sottodomini.
Il problema nasce quando non sappiamo più cosa rappresentano, chi li gestisce o se siano ancora necessari.
Ed è proprio qui che un semplice inventario del dominio principale può non essere sufficiente.
Cos'è un sottodominio?
Un sottodominio è semplicemente una parte del dominio principale utilizzata per identificare un servizio o un ambiente specifico.
Per esempio:
example.com
può avere:
www.example.com
api.example.com
blog.example.com
shop.example.com
È una configurazione assolutamente normale.
Un'organizzazione potrebbe utilizzare api.example.com per le proprie API e shop.example.com per l'e-commerce.
Il fatto che un sottodominio esista non significa quindi che ci sia un problema di sicurezza.
La questione interessante è un'altra:
Sappiamo esattamente quali sottodomini abbiamo e cosa c'è dietro ognuno di essi?
Come nasce un sottodominio dimenticato?
Spesso in modo molto semplice.
Un team deve sviluppare una nuova funzionalità e crea:
staging.example.com
Il progetto viene completato.
La nuova applicazione viene pubblicata.
Lo staging, però, rimane online.
Oppure un'azienda migra un'API:
api.example.com
verso una nuova infrastruttura:
api-v2.example.com
La vecchia API continua però a rispondere.
Dopo qualche anno potrebbe non essere più chiaro chi gestisca api.example.com.
Questo genere di situazione può creare una zona d'ombra nella superficie di attacco.
Un sottodominio non utilizzato è sempre pericoloso?
No.
È importante non confondere un asset dimenticato con una vulnerabilità.
Un sottodominio potrebbe semplicemente mostrare:
404 Not Found
oppure potrebbe essere correttamente configurato e non contenere alcuna informazione sensibile.
Tuttavia, se nessuno sa che esiste, diventa difficile sapere se sia configurato correttamente.
Il problema principale è quindi spesso la mancanza di visibilità.
Perché i sottodomini sono interessanti durante un security assessment?
OWASP considera la scoperta di domini, sottodomini, virtual host e servizi esposti una parte importante dell'identificazione della superficie di attacco. La guida OWASP evidenzia inoltre che la scoperta può far emergere sistemi di sviluppo, staging, servizi legacy e interfacce amministrative che non erano inizialmente presenti nello scope conosciuto.
Immaginiamo:
example.com
e:
admin.example.com
Il secondo potrebbe essere perfettamente legittimo.
Ma se non sapevamo che esistesse, vale la pena capire:
- chi lo utilizza;
- a cosa serve;
- se è ancora necessario;
- come è protetto;
- quale software utilizza.
Staging, dev e test
Alcuni nomi sono particolarmente interessanti:
dev.example.com
test.example.com
staging.example.com
qa.example.com
uat.example.com
Naturalmente non significa che ogni sottodominio con uno di questi nomi sia vulnerabile.
Ma spesso indicano ambienti differenti dalla produzione.
Ed è proprio questa differenza che può essere importante.
Un ambiente di sviluppo potrebbe avere:
debug = true
oppure utilizzare una versione del software diversa da quella presente in produzione.
Potrebbe inoltre contenere funzionalità che non sono ancora state pubblicate.
Vecchi sottodomini e vecchie applicazioni
Un'altra situazione comune è quella delle applicazioni legacy.
Per esempio:
old.example.com
legacy.example.com
v1.example.com
Un'azienda potrebbe aver sostituito un'applicazione senza rimuovere completamente quella precedente.
Magari nessuno la utilizza più.
Ma se il server continua a rispondere, quella vecchia applicazione fa ancora parte della superficie pubblica.
In questo caso la domanda più importante è molto semplice:
Serve ancora?
Se la risposta è no, rimuoverla può essere più utile che continuare semplicemente a monitorarla.
Come si possono scoprire i sottodomini?
Esistono diversi approcci.
Tra le fonti utilizzabili ci sono:
- record DNS pubblici;
- Certificate Transparency;
- dati DNS passivi;
- motori di ricerca;
- database pubblici;
- informazioni storiche;
- enumerazione attiva, quando autorizzata.
Un certificato TLS, per esempio, può contenere diversi nomi nei campi Subject Alternative Name.
In alcuni casi può quindi comparire:
DNS:example.com
DNS:www.example.com
DNS:api.example.com
DNS:staging.example.com
Questo non significa necessariamente che tutti gli host siano ancora attivi, ma fornisce un'indicazione utile da verificare.
OWASP cita proprio DNS enumeration, Certificate Transparency e analisi dei certificati tra le tecniche utili per ampliare la conoscenza della superficie di attacco.
Un sottodominio può diventare una vulnerabilità?
Sì, in determinate condizioni.
Uno dei casi più conosciuti è il Subdomain Takeover.
Può verificarsi quando un record DNS continua a puntare verso una risorsa esterna che non esiste più o non è più controllata dall'organizzazione.
Per esempio:
blog.example.com
↓
CNAME
↓
example-service.provider.com
Se il servizio viene eliminato ma il record DNS rimane, si può creare una situazione anomala.
Non significa automaticamente che il takeover sia possibile.
È necessario verificare il comportamento del servizio e le condizioni specifiche.
Ma è un esempio perfetto di come un semplice record DNS dimenticato possa diventare un problema di sicurezza.
Il problema non è solo tecnico
Molti casi di sottodomini dimenticati nascono da un problema organizzativo.
Magari:
- il reparto sviluppo gestisce l'applicazione;
- il reparto IT gestisce il DNS;
- un fornitore gestisce il cloud;
- un'agenzia gestisce il sito;
- nessuno ha un inventario aggiornato.
Quando il servizio viene dismesso, il DNS potrebbe non essere aggiornato.
Questo è uno dei motivi per cui la gestione della superficie di attacco non è soltanto una questione tecnica.
È anche una questione di inventario e responsabilità.
Come gestire correttamente i sottodomini
Una buona gestione parte da un inventario.
Per ogni sottodominio potrebbe essere utile conoscere:
Hostname
Funzione
Responsabile
Destinazione
Ambiente
Stato
Per esempio:
api.example.com
Funzione: API pubblica
Ambiente: Produzione
Responsabile: Team Backend
Stato: Attivo
oppure:
staging.example.com
Funzione: Ambiente di test
Ambiente: Staging
Responsabile: Team Development
Stato: Da verificare
Questo semplice approccio può già ridurre parecchie zone d'ombra.
Cosa fare quando trovi un sottodominio sconosciuto?
Non eliminarlo immediatamente.
Prima prova a capire:
- A quale indirizzo risolve?
- Quale servizio risponde?
- Chi lo gestisce?
- Quale applicazione utilizza?
- È ancora necessario?
- Contiene dati o funzionalità importanti?
- È correttamente protetto?
- Esistono vulnerabilità note?
- Il DNS punta ancora alla destinazione prevista?
Solo dopo queste verifiche puoi decidere se:
- mantenerlo;
- limitarne l'accesso;
- correggerne la configurazione;
- migrare il servizio;
- rimuoverlo.
Una piccola checklist
[ ] Ho un inventario dei sottodomini?
[ ] So chi gestisce ogni sottodominio?
[ ] So a quale servizio punta?
[ ] Esistono ambienti dev/staging/test?
[ ] Ci sono vecchie applicazioni ancora online?
[ ] Ci sono sottodomini che non riconosco?
[ ] Esistono record DNS verso servizi esterni?
[ ] Ci sono record DNS che puntano a risorse non più esistenti?
[ ] I sottodomini utilizzano HTTPS correttamente?
[ ] I servizi sono ancora necessari?
La superficie che non vedi può comunque esistere
Uno dei motivi per cui la discovery è così importante è che l'assenza di un link dalla homepage non significa che un servizio non esista.
Un'applicazione può essere raggiungibile direttamente attraverso:
https://admin.example.com
anche se il link non compare da nessuna parte sul sito principale.
Per questo l'analisi della superficie esterna non dovrebbe limitarsi a seguire i link presenti nelle pagine web.
Bisogna cercare di costruire una visione più ampia dell'infrastruttura.
Conclusione
Un sottodominio dimenticato non è automaticamente una vulnerabilità.
È però un elemento della superficie di attacco che potrebbe essere stato escluso dall'inventario e quindi non essere più controllato correttamente.
La cosa più importante è quindi sapere quali sottodomini esistono, cosa fanno e perché sono ancora online.
E se ne trovi uno che nessuno riconosce?
Quello è probabilmente un buon punto da cui iniziare a fare qualche domanda.
Trova gli asset che potresti aver dimenticato
MiHakero analizza la superficie pubblica associata ai tuoi domini e può aiutarti a individuare applicazioni, API e servizi che meritano una verifica.
L'obiettivo non è considerare ogni asset sconosciuto come una vulnerabilità, ma aiutarti a capire cosa esiste realmente e cosa richiede attenzione.