Quando pensiamo a ciò che un sito web rende pubblico, probabilmente pensiamo alla homepage, alle pagine del sito e alle API.
In realtà, prima ancora di visitare il sito, è possibile ottenere molte informazioni attraverso il DNS.
Il processo di raccolta e analisi di queste informazioni viene spesso chiamato DNS enumeration.
Il termine può sembrare molto tecnico, ma il concetto è semplice:
cercare di capire quali nomi, server e servizi sono associati pubblicamente a un dominio.
Questa attività può essere utilizzata per motivi legittimi, come costruire un inventario della propria infrastruttura, ma può anche essere utilizzata da chi sta cercando di capire come è strutturata un'organizzazione.
Cosa può rivelare il DNS?
Partendo da:
example.com
si possono trovare informazioni relative a:
www.example.com
api.example.com
mail.example.com
vpn.example.com
dev.example.com
staging.example.com
Non significa che tutti questi nomi esistano.
Ma quando esistono, possono fornire una visione più ampia dell'infrastruttura rispetto al solo sito principale.
Un esempio
Immaginiamo che il sito pubblico sia:
https://example.com
Un controllo DNS potrebbe rivelare:
www.example.com
api.example.com
mail.example.com
status.example.com
A questo punto l'organizzazione sa di avere almeno quattro componenti pubblicamente identificabili oltre al dominio principale.
Per chi gestisce la sicurezza, questa è un'informazione utile.
DNS enumeration non significa attaccare un sistema
È importante distinguere la raccolta di informazioni dall'attacco.
Osservare i record DNS pubblici non significa sfruttare una vulnerabilità.
Per esempio:
dig example.com
è una normale interrogazione DNS.
Il valore dell'attività sta nell'organizzare le informazioni ottenute e capire cosa rappresentano.
Quali record sono particolarmente interessanti?
Tra i record più utili per comprendere un'infrastruttura troviamo:
A e AAAA
Possono indicare gli indirizzi IP associati a un hostname.
example.com → IPv4
example.com → IPv6
CNAME
Possono mostrare collegamenti verso servizi esterni.
blog.example.com → provider.example.net
MX
Indicano quali sistemi gestiscono la posta.
example.com → mail.provider.com
NS
Permettono di capire quali nameserver sono autorevoli per il dominio.
TXT
Possono contenere informazioni relative a verifiche e servizi.
I sottodomini sono particolarmente interessanti
Uno degli obiettivi più utili dell'inventario DNS è capire quali sottodomini esistono.
Per esempio:
api.example.com
dev.example.com
staging.example.com
admin.example.com
portal.example.com
Alcuni possono essere perfettamente normali.
Altri potrebbero appartenere a vecchi progetti.
Altri ancora potrebbero essere ambienti temporanei che non sono mai stati dismessi.
È proprio questo il punto:
non bisogna dare per scontato che ogni hostname conosciuto sia ancora necessario.
Il problema degli ambienti di sviluppo
Un nome come:
dev.example.com
non significa automaticamente che il server sia vulnerabile.
Potrebbe essere:
- correttamente protetto;
- accessibile solo tramite VPN;
- utilizzato internamente;
- pubblicamente raggiungibile ma autenticato.
Il problema nasce quando l'organizzazione non sa nemmeno che esiste.
La sicurezza migliora quando ogni risorsa pubblica ha un proprietario e una motivazione.
DNS enumeration e attack surface
Possiamo rappresentare il concetto in questo modo:
Dominio
↓
DNS
↓
Hostname
↓
IP / servizio
↓
Applicazione
↓
Possibili problemi di sicurezza
Il DNS rappresenta quindi uno dei primi livelli dell'analisi.
Una risorsa non può essere valutata correttamente se prima non sappiamo che esiste.
Non tutti i sottodomini sono uguali
È utile classificare le risorse.
Per esempio:
| Hostname | Funzione | Pubblico | Proprietario | | ----------------------------------------- | ----------- | -------- | ------------ | | www.example.com | Sito | Sì | Web | | api.example.com | API | Sì | Dev | | mail.example.com | Posta | Sì | IT | | staging.example.com | Test | Sì | Dev | | old.example.com | Sconosciuta | Sì | Nessuno |
L'ultimo elemento dovrebbe attirare l'attenzione.
Non perché sia necessariamente vulnerabile.
Perché non dovrebbe esistere una risorsa pubblica senza che nessuno sappia cosa sia.
DNS enumeration e certificati
Il DNS non è l'unica fonte di informazioni.
Come abbiamo visto, anche i Certificate Transparency logs possono fornire hostname associati ai certificati.
Le due fonti possono quindi essere confrontate.
Per esempio:
DNS:
api.example.com
www.example.com
Certificate Transparency:
api.example.com
www.example.com
staging.example.com
old-api.example.com
Le differenze possono essere interessanti.
staging.example.com potrebbe essere un ambiente ancora attivo.
old-api.example.com potrebbe invece appartenere a una vecchia infrastruttura.
In entrambi i casi serve una verifica.
Cosa fare quando trovi un hostname sconosciuto?
La prima cosa da evitare è saltare direttamente alla conclusione che sia una vulnerabilità.
Meglio seguire una sequenza semplice:
- verificare il record DNS;
- identificare la destinazione;
- verificare se il servizio è attivo;
- capire a cosa serve;
- individuare il proprietario;
- verificare se dovrebbe essere pubblico;
- decidere se mantenerlo, proteggerlo o rimuoverlo.
Questo approccio riduce anche i falsi positivi.
L'obiettivo non è nascondere l'infrastruttura
Non è realistico pensare di rendere completamente invisibile un'infrastruttura pubblica.
Un sito web deve essere raggiungibile.
Un'API pubblica deve poter essere raggiunta.
Un servizio email deve avere una configurazione DNS.
L'obiettivo della sicurezza non è quindi:
"nessuno deve sapere che esiste".
È piuttosto:
"sappiamo cosa è pubblico e sappiamo perché lo è".
Questa differenza è fondamentale.
Una buona procedura di inventario
Per mantenere sotto controllo la superficie DNS è utile effettuare periodicamente:
Raccolta
↓
Normalizzazione
↓
Classificazione
↓
Verifica
↓
Assegnazione del proprietario
↓
Rimozione degli elementi inutili
In questo modo l'inventario diventa un processo continuo invece di un controllo effettuato una sola volta.
In sintesi
Il DNS può rivelare molte più informazioni di quanto sembri.
Attraverso record e hostname è possibile ricostruire una parte della struttura pubblica di un'organizzazione:
- siti;
- API;
- posta;
- servizi esterni;
- ambienti di sviluppo;
- staging;
- vecchie infrastrutture.
Queste informazioni non sono automaticamente un problema.
Diventano interessanti quando vengono confrontate con ciò che l'organizzazione sa di avere.
La vera domanda da porsi non è:
"Possiamo impedire che qualcuno scopra i nostri sottodomini?"
ma:
"Sappiamo esattamente quali sottodomini sono pubblici e cosa c'è dietro ciascuno di essi?"
Questo è uno dei principi fondamentali dell'attack surface management.
MiHakero nasce proprio per aiutare a rispondere a questa domanda: osservare la superficie pubblicamente rilevabile, organizzare ciò che viene trovato e dare priorità agli elementi che richiedono maggiore attenzione.