Collegare un sottodominio a un servizio esterno è una pratica normalissima.
Un'azienda può avere, per esempio:
blog.example.com
gestito da una piattaforma esterna, oppure:
support.example.com
collegato a un servizio di assistenza clienti.
Per fare questo vengono spesso utilizzati i record CNAME.
Il problema non è utilizzare servizi esterni.
Il problema nasce quando il collegamento rimane attivo più a lungo della risorsa a cui punta.
Cos'è un CNAME?
Un record CNAME permette di indicare che un nome DNS deve essere considerato un alias di un altro nome.
Per esempio:
blog.example.com → customer.example-provider.com
Quando qualcuno cerca blog.example.com, il DNS indica che la destinazione deve essere cercata seguendo il nome indicato dal CNAME.
È una soluzione molto utilizzata per collegare sottodomini a piattaforme SaaS, hosting, CDN e altri servizi.
Perché i servizi esterni sono interessanti dal punto di vista della sicurezza?
Quando un servizio è gestito internamente, normalmente l'organizzazione controlla direttamente:
- server;
- applicazione;
- configurazione;
- account;
- rete.
Con un servizio esterno, invece, una parte del controllo passa a un'altra organizzazione.
Questo non significa che il servizio sia meno sicuro.
Significa semplicemente che bisogna gestire anche il rapporto tra il proprio dominio e il servizio esterno.
Un esempio concreto
Immaginiamo:
status.example.com
↓
status.provider.com
Il CNAME è stato creato quando l'azienda ha attivato una piattaforma per la pagina di stato.
Dopo qualche anno il servizio viene dismesso.
L'account viene eliminato, ma il DNS rimane:
status.example.com → status.provider.com
A questo punto bisogna verificare cosa succede alla destinazione.
Il semplice fatto che il CNAME esista non dimostra la presenza di una vulnerabilità.
È però una configurazione che non dovrebbe essere lasciata senza controllo.
Il rischio dei riferimenti "orfani"
Il caso più interessante è quello dei cosiddetti riferimenti DNS orfani.
In pratica:
Sottodominio
↓
CNAME
↓
Servizio esterno
↓
Risorsa eliminata
Il DNS continua a esistere, mentre la risorsa associata non è più gestita dall'organizzazione.
In determinate condizioni, questo può portare a un subdomain takeover.
Non tutti i CNAME orfani sono sfruttabili.
La possibilità dipende dal provider e dalle caratteristiche del servizio.
Per questo motivo un risultato automatico dovrebbe essere considerato un segnale da verificare, non una vulnerabilità confermata.
Non sono soltanto i CNAME a richiedere attenzione
Lo stesso principio può riguardare altre integrazioni.
Per esempio:
- servizi di hosting;
- CDN;
- piattaforme SaaS;
- servizi di email;
- piattaforme di ticketing;
- sistemi di analytics;
- landing page;
- servizi per sviluppatori;
- piattaforme di monitoraggio.
Ogni volta che un dominio viene collegato a una piattaforma esterna, esiste una relazione che dovrebbe essere conosciuta e documentata.
Come fare un controllo
Per prima cosa è utile ottenere l'elenco dei CNAME.
Un controllo manuale può essere effettuato con:
dig CNAME blog.example.com
oppure:
dig CNAME status.example.com
Il risultato permette di capire verso quale hostname viene indirizzato il sottodominio.
A questo punto la domanda diventa:
quel servizio esiste ancora ed è sotto il nostro controllo?
Un piccolo inventario può evitare molti problemi
Per ogni servizio esterno può essere utile mantenere informazioni come:
| Sottodominio | Provider | Servizio | Proprietario | Stato | | ------------------ | ---------- | ------------ | ------------ | ------------- | | blog.example.com | Provider A | Blog | Marketing | Attivo | | status.example.com | Provider B | Status page | IT | Attivo | | old.example.com | Provider C | Landing page | — | Da verificare |
Questo rende molto più semplice individuare i record che nessuno ricorda più.
Attenzione alle migrazioni
Le migrazioni sono uno dei momenti più delicati.
Supponiamo che:
old.example.com → provider-A.com
venga sostituito da:
old.example.com → provider-B.com
Il vecchio servizio potrebbe essere stato disattivato correttamente.
Ma cosa succede se ci si dimentica di eliminare altri sottodomini?
Per esempio:
dev.example.com
test.example.com
preview.example.com
old-api.example.com
Sono proprio questi elementi secondari che spesso sfuggono all'inventario.
Cosa controllare periodicamente
Per i servizi esterni è utile verificare:
- quali CNAME esistono;
- a quali provider puntano;
- chi è il proprietario del servizio;
- se il servizio è ancora utilizzato;
- se l'account corrispondente esiste ancora;
- se il sottodominio è ancora necessario;
- se la destinazione può essere reclamata da terzi;
- se il record deve essere eliminato dopo la dismissione.
Una regola semplice
Quando elimini un servizio esterno, non limitarti a cancellare l'account.
Controlla anche:
Account
+
Servizio
+
DNS
+
Certificato
+
Documentazione
La dismissione dovrebbe riguardare l'intero collegamento.
In sintesi
I CNAME sono uno strumento estremamente utile e non rappresentano di per sé un rischio.
Il problema nasce quando vengono utilizzati per collegare un sottodominio a un servizio esterno che successivamente viene:
- abbandonato;
- migrato;
- cancellato;
- sostituito;
- dimenticato.
Un inventario aggiornato dei servizi esterni e dei relativi record DNS riduce notevolmente la possibilità di lasciare collegamenti inutilizzati.
La sicurezza del dominio non dipende soltanto dal server principale.
Dipende anche da tutti i servizi che il dominio continua a indicare.
MiHakero può aiutare a individuare elementi della superficie pubblica che meritano una verifica, compresi hostname e servizi che potrebbero essere sfuggiti all'inventario interno.