Quando viene emesso un certificato TLS per un dominio, una parte delle informazioni relative al certificato può diventare pubblicamente osservabile attraverso i Certificate Transparency logs.
Per chi gestisce un'infrastruttura web, questo è un dettaglio interessante.
Perché?
Perché i certificati possono rivelare nomi di dominio e sottodomini che magari non sono immediatamente visibili navigando il sito.
Immaginiamo un certificato associato a:
example.com
www.example.com
api.example.com
staging.example.com
Il sito principale potrebbe mostrare soltanto:
https://example.com
ma il certificato può fornire informazioni aggiuntive.
Cos'è Certificate Transparency?
Certificate Transparency, spesso abbreviato in CT, è un sistema pensato per rendere più trasparente l'emissione dei certificati TLS.
I certificati emessi dalle Certificate Authority vengono registrati in appositi log pubblici.
L'obiettivo principale è permettere di individuare più facilmente certificati emessi in modo improprio o inatteso.
Ma questa trasparenza produce anche un effetto collaterale interessante per la sicurezza:
i nomi presenti nei certificati possono diventare una fonte di informazioni sull'infrastruttura.
Un esempio semplice
Supponiamo che un'organizzazione utilizzi:
example.com
www.example.com
api.example.com
Successivamente crea un ambiente di test:
staging.example.com
e gli assegna un certificato TLS.
Anche se il sito staging.example.com non compare nei menu del sito principale, il nome potrebbe comunque essere osservabile attraverso i log CT.
Questo non significa che il server sia vulnerabile.
Significa semplicemente che il nome può essere scoperto più facilmente.
Perché è importante per l'attack surface?
La superficie di attacco comprende tutte le risorse potenzialmente raggiungibili o identificabili dall'esterno.
Un nuovo sottodominio può rappresentare una nuova risorsa:
api.example.com
oppure:
admin.example.com
oppure:
dev.example.com
La sua presenza nei Certificate Transparency logs può quindi diventare un punto di partenza per l'inventario.
In altre parole:
Certificato
↓
Nome del dominio
↓
Possibile sottodominio
↓
Verifica DNS
↓
Verifica del servizio
Il passaggio importante è l'ultimo.
Scoprire un hostname non significa aver scoperto una vulnerabilità.
È necessario verificare cosa esiste realmente dietro quel nome.
Quali informazioni possono emergere?
A seconda del certificato, possono comparire diversi nomi tramite il campo Subject Alternative Name, comunemente indicato come SAN.
Per esempio:
example.com
www.example.com
api.example.com
mail.example.com
vpn.example.com
Questi nomi possono fornire una visione interessante dell'organizzazione.
In alcuni casi possono emergere anche nomi relativi a:
- ambienti di sviluppo;
- staging;
- API;
- pannelli;
- portali;
- servizi interni accidentalmente pubblicati;
- vecchie infrastrutture.
Naturalmente, non tutti questi nomi indicano necessariamente servizi attivi.
Certificate Transparency non è un errore di sicurezza
È importante chiarire questo punto.
La presenza di un hostname nei Certificate Transparency logs non costituisce di per sé una vulnerabilità.
Anzi, la trasparenza dei certificati è una caratteristica di sicurezza importante.
Il problema può nascere quando le informazioni ottenute vengono combinate con altre fonti.
Per esempio:
CT log
+
DNS
+
HTTP
+
inventario interno
può permettere di ricostruire una parte significativa della superficie pubblica.
Un controllo pratico
Se stai facendo un inventario autorizzato dei tuoi domini, puoi partire dai nomi pubblicamente associati ai certificati e successivamente verificare quali risultano effettivamente attivi.
Per ogni hostname puoi raccogliere informazioni come:
Hostname
Stato DNS
Indirizzo IP
Servizio HTTP/HTTPS
Certificato
Data dell'ultima verifica
A quel punto puoi confrontare il risultato con l'inventario interno.
Se compare:
staging.example.com
ma nessuno nell'organizzazione sa perché esista, vale la pena approfondire.
Il problema dei vecchi certificati
Un'altra situazione interessante è quella dei certificati relativi a infrastrutture ormai dismesse.
Un hostname potrebbe essere apparso in passato perché utilizzato da un vecchio progetto.
Questo non significa necessariamente che il servizio sia ancora online.
Per questo motivo è importante non confondere:
"il nome è stato osservato"
con:
"il servizio è attualmente esposto".
Sono due informazioni differenti.
Certificate Transparency e gestione dell'inventario
CT può quindi essere considerato una delle fonti utili per costruire un inventario esterno.
Un processo ragionevole può essere:
- individuare i domini principali;
- raccogliere gli hostname osservabili;
- verificare la risoluzione DNS;
- verificare quali host risultano effettivamente raggiungibili;
- identificare i servizi;
- confrontare i risultati con l'inventario ufficiale;
- approfondire ciò che non viene riconosciuto.
Questo approccio è particolarmente utile nelle organizzazioni dove i domini e i servizi cambiano frequentemente.
Cosa dovrebbe far scattare un controllo?
Alcuni esempi:
admin.example.com
dev.example.com
staging.example.com
old-api.example.com
vpn.example.com
Non perché questi nomi siano automaticamente pericolosi.
Piuttosto perché possono indicare componenti che devono essere identificati e classificati.
Un staging correttamente protetto non è un problema.
Un staging dimenticato e accessibile pubblicamente potrebbe invece diventarlo.
La differenza sta nella configurazione e nel contesto.
In sintesi
Certificate Transparency non deve essere visto come un nemico.
È una componente importante dell'ecosistema dei certificati TLS e contribuisce alla possibilità di individuare emissioni anomale.
Dal punto di vista della sicurezza, però, i suoi log rappresentano anche una fonte di informazioni utile per capire quali hostname sono stati associati ai certificati di un'organizzazione.
Il valore reale nasce quando queste informazioni vengono confrontate con ciò che dovrebbe essere esposto.
La domanda da porsi non è quindi:
"Quali domini posso trovare?"
ma:
"Quali dei domini che risultano pubblicamente associati alla mia organizzazione dovrebbero essere ancora presenti?"
È questa differenza che trasforma una semplice raccolta di informazioni in una vera attività di attack surface management.
MiHakero parte proprio da questo principio: osservare ciò che è rilevabile dall'esterno, organizzare le informazioni e aiutarti a capire quali elementi meritano attenzione.