Condividi tramite

Evitare voci DNS inesatte ed evitare l'acquisizione di sottodomini

  • Articolo

Questo articolo descrive la minaccia comune per la sicurezza dell'acquisizione del sottodominio e i passaggi che è possibile eseguire per attenuarlo.

Che cos'è l'acquisizione di un sottodominio?

Le acquisizioni di sottodomini sono una minaccia comune a gravità elevata per le organizzazioni che creano ed eliminano regolarmente molte risorse. Un'acquisizione di sottodominio può verificarsi quando è presente un record DNS che punta a una risorsa di Azure di cui è stato effettuato il deprovisioning. Tali record DNS sono noti anche come voci "DNS in sospeso". I record CNAME sono particolarmente vulnerabili a questa minaccia. Le acquisizioni di sottodomini consentono agli utenti malintenzionati di reindirizzare il traffico destinato al dominio di un'organizzazione a un sito che esegue attività dannose.

Uno scenario comune per l'acquisizione di un sottodominio:

  1. CREAZIONE:

    1. Si effettua il provisioning di una risorsa di Azure con un nome di dominio completo (FQDN) di app-contogreat-dev-001.azurewebsites.net.

    2. Si assegna un record CNAME nella zona DNS con il sottodominio greatapp.contoso.com che instrada il traffico alla risorsa di Azure.

  2. DEPROVISIONING:

    1. La risorsa di Azure viene deprovisionata o eliminata dopo che non è più necessaria.

      A questo punto, il record CNAME greatapp.contoso.comdovrebbe essere rimosso dalla zona DNS. Se il record CNAME non viene rimosso, viene annunciato come dominio attivo, ma non instrada il traffico a una risorsa di Azure attiva. È ora disponibile un record DNS "in sospeso".

    2. Il sottodominio in sospeso, greatapp.contoso.com, è ora vulnerabile ed è possibile assumerlo o tramite l'assegnazione a una risorsa di un'altra sottoscrizione di Azure.

  3. TAKEOVER:

    1. Usando metodi e strumenti comunemente disponibili, un attore di minacce individua il sottodominio in sospeso.

    2. L'attore di minaccia effettua il provisioning di una risorsa di Azure con lo stesso FQDN della risorsa controllata in precedenza. In questo esempio, app-contogreat-dev-001.azurewebsites.net.

    3. Il traffico inviato al sottodominio greatapp.contoso.com viene ora indirizzato alla risorsa dell'attore malintenzionato in cui controllano il contenuto.

Acquisizione del sottodominio da un sito Web con deprovisioning

I rischi dell'acquisizione del sottodominio

Quando un record DNS punta a una risorsa non disponibile, il record stesso dovrebbe essere rimosso dalla zona DNS. Se non viene eliminato, si tratta di un record "DNS in sospeso" e crea la possibilità di acquisizione del sottodominio.

Gli attori delle minacce possono assumere il controllo del nome DNS associato per ospitare un sito Web o un servizio dannoso. Le pagine e i servizi dannosi nel sottodominio di un'organizzazione possono comportare:

  • Perdita di controllo sul contenuto del sottodominio : stampa negativa sull'impossibilità dell'organizzazione di proteggere il contenuto, i danni al marchio e la perdita di fiducia.

  • Raccolta di cookie da visitatori insospettabili: è comune che le app Web esponga i cookie di sessione ai sottodomini (*.contoso.com). Qualsiasi sottodominio può accedervi. Gli attori delle minacce possono usare l'acquisizione del sottodominio per creare una pagina di ricerca autentica, ingannare gli utenti insospettabili da visitare e raccogliere i loro cookie (anche cookie sicuri). Un malinteso comune è che l'uso dei certificati SSL protegge il sito e i cookie degli utenti da un'acquisizione. Tuttavia, un attore di minacce può usare il sottodominio di hijacked per richiedere e ricevere un certificato SSL valido. I certificati SSL validi concedono loro l'accesso ai cookie sicuri e possono aumentare ulteriormente la legittimità percepita del sito dannoso.

  • Campagne di phishing: gli attori malintenzionati spesso sfruttano sottodomini autenticati nelle campagne di phishing. Il rischio si estende sia ai siti Web dannosi che ai record MX, che potrebbero consentire agli attori delle minacce di ricevere messaggi e-mail indirizzati a sottodomini legittimi associati a marchi attendibili.

  • Altri rischi : i siti dannosi potrebbero essere usati per inoltrare in altri attacchi classici, ad esempio XSS, CSRF, bypass CORS e altro ancora.

Identificare le voci DNS in sospeso

Per identificare le voci DNS all'interno dell'organizzazione che potrebbero essere in sospeso, usare gli strumenti di PowerShell ospitati da GitHub di Microsoft "Get-DanglingDnsRecords".

Questo strumento consente ai clienti di Azure di elencare tutti i domini con un record CNAME associato a una risorsa di Azure esistente creata nelle sottoscrizioni o nei tenant.

Se i record CNAME si trovano in altri servizi DNS e puntano alle risorse di Azure, fornire i record CNAME in un file di input allo strumento.

Lo strumento supporta le risorse di Azure elencate nella tabella seguente. Lo strumento estrae o accetta come input tutti i CNAM del tenant.

Service Type FQDNproperty Esempio
Frontdoor di Azure microsoft.network/frontdoors properties.cName abc.azurefd.net
Archiviazione BLOB di Azure microsoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.windows.net
Rete CDN di Azure microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net
Indirizzi IP pubblici microsoft.network/publicipaddresses properties.dnsSettings.fqdn abc.EastUs.cloudapp.azure.com
Gestione traffico di Azure microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.net
Azure Container Instance microsoft.containerinstance/containergroups properties.ipAddress.fqdn abc.EastUs.azurecontainer.io
Gestione API di Azure microsoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net
Servizio app di Azure microsoft.web/sites properties.defaultHostName abc.azurewebsites.net
Servizio app di Azure - Slot microsoft.web/sites/slots properties.defaultHostName abc-def.azurewebsites.net

Prerequisiti

Eseguire la query come utente che ha:

  • almeno l'accesso a livello di lettore alle sottoscrizioni di Azure
  • accesso in lettura a Azure Resource Graph

Se si è un amministratore globale del tenant dell'organizzazione, seguire le indicazioni riportate in Elevare l'accesso per gestire tutte le sottoscrizioni e i gruppi di gestione di Azure per ottenere l'accesso a tutte le sottoscrizioni dell'organizzazione

Suggerimento

Azure Resource Graph presenta limiti di limitazione e paging che è consigliabile prendere in considerazione se si dispone di un ambiente diAzure di grandi dimensioni.

Altre informazioni sull'uso di set di dati di risorse di Azure di grandi dimensioni.

Lo strumento usa l'invio in batch delle sottoscrizioni per evitare queste limitazioni.

Eseguire lo script

Altre informazioni sullo script di PowerShell, Get-DanglingDnsRecords.ps1e scaricarlo da GitHub: https://aka.ms/Get-DanglingDnsRecords.

Correggere le voci di tipo DNS in sospeso

Esaminare le zone DNS e identificare i record CNAME in sospeso o acquisiti. Se vengono rilevati sottodomini in sospeso o acquisiti, rimuovere i sottodomini vulnerabili e attenuare i rischi con i passaggi seguenti:

  1. Dalla zona DNS rimuovere tutti i record CNAME che puntano ai nomi di dominio completi delle risorse di cui non è più stato effettuato il provisioning.

  2. Per consentire il routing del traffico alle risorse sotto il proprio controllo, effettuare il provisioning di risorse aggiuntive con i nomi di dominio completi specificati nei record CNAME dei sottodomini in sospeso.

  3. Esaminare il codice dell'applicazione per i riferimenti a sottodomini specifici e aggiornare eventuali riferimenti al sottodominio non corretti oppure obsoleti.

  4. Determinare se si è verificata una compromissione e intervenire in base alle procedure di risposta agli incidenti dell'organizzazione. Suggerimenti e procedure consigliate per l'analisi:

    Se la logica dell'applicazione comporta segreti, ad esempio le credenziali OAuth, essere inviati a sottodomini incerti o se le informazioni sensibili alla privacy vengono trasmesse a tali sottodomini, è possibile che questi dati vengano esposti a terze parti.

  5. Comprendere il motivo per cui il record CNAME non è stato rimosso dalla zona DNS quando la risorsa è stata sottoposta a deprovisioning e intervenire per assicurarsi che i record DNS vengano aggiornati in modo appropriato quando viene effettuato in futuro il deprovisioning delle risorse di Azure.

Impedire voci DNS in sospeso

Assicurarsi che l'organizzazione abbia implementato processi per evitare voci DNS in sospeso e che le acquisizioni di sottodomini risultanti siano una parte fondamentale del programma di sicurezza.

Alcuni servizi di Azure offrono funzionalità utili per la creazione di misure preventive e sono descritti in dettaglio di seguito. È necessario stabilire altri metodi per evitare questo problema tramite le procedure consigliate o le procedure operative standard dell'organizzazione.

Abilitare Microsoft Defender per il Servizio app

La piattaforma CWPP (Cloud Workload Protection Platform) integrata di Microsoft Defender for Cloud offre una gamma di piani per proteggere le risorse e i carichi di lavoro di Azure, ibridi e multicloud.

Il piano di Microsoft Defender per il Servizio app include il rilevamento DNS in sospeso. Con questo piano abilitato, si riceveranno avvisi di sicurezza se si rimuove un sito Web del Servizio app ma non si rimuove il dominio personalizzato dal registrar DNS.

La protezione DNS incerta di Microsoft Defender for Cloud è disponibile se i domini vengono gestiti con DNS di Azure o con un registrar di dominio esterno e si applicano al Servizio app sia in Windows che in Linux.

Altre informazioni su questo e altri vantaggi di questo piano di Microsoft Defender sono disponibili in Introduzione a Microsoft Defender per il Servizio app.

Usare i record alias DNS di Azure

I record alias di DNS di Azure prevengono i riferimenti in sospeso accoppiando il ciclo di vita di un record DNS a una risorsa di Azure. Si consideri, ad esempio, un record DNS che è qualificato come record alias per puntare a un indirizzo IP pubblico o a un profilo di Gestione traffico. Se si eliminano tali risorse sottostanti, il record alias DNS diventa un set di record vuoto. Non fa più riferimento alla risorsa eliminata. È importante notare che esistono limiti a ciò che è possibile proteggere con i record alias. Oggi, l'elenco è limitato a:

  • Frontdoor di Azure
  • Profili di Gestione traffico
  • Endpoint della Rete di distribuzione dei contenuti (CDN) di Azure
  • IP pubblici

Nonostante le offerte di servizi limitate, è consigliabile usare record alias per difendersi dall'acquisizione del sottodominio quando possibile.

Altre informazioni sulle funzionalità dei record alias di DNS di Azure.

Usare la verifica del dominio personalizzato del Servizio app di Azure

Quando si creano voci DNS per il Servizio app di Azure, creare un asuid. {sottodominio} Record TXT con l'ID di verifica del dominio. Quando esiste un record TXT di questo tipo, nessun'altra sottoscrizione di Azure può convalidare il dominio personalizzato, assumerlo.

Questi record non impediscono a un utente di creare il Servizio app di Azure con lo stesso nome presente nella voce CNAME. Senza la possibilità di dimostrare la proprietà del nome di dominio, gli attori delle minacce non possono ricevere traffico o controllare il contenuto.

Altre informazioni su come eseguire il mapping di un nome DNS personalizzato esistente al Servizio app di Azure.

Creare e automatizzare i processi per attenuare la minaccia

È spesso necessario che gli sviluppatori e i team operativi eseguano processi di pulizia per evitare minacce DNS in sospeso. Le procedure seguenti consentiranno di garantire che l'organizzazione eviti di soffrire di questa minaccia.

  • Creare procedure per la prevenzione:

    • Informare gli sviluppatori dell'applicazione di reindirizzare gli indirizzi ogni volta che eliminano le risorse.

    • Inserire "Rimuovi voce DNS" nell'elenco dei controlli necessari durante la rimozione delle autorizzazioni di un servizio.

    • Inserire blocchi di eliminazione su qualsiasi risorsa con una voce DNS personalizzata. Un blocco di eliminazione funge da indicatore che il mapping deve essere rimosso prima del deprovisioning della risorsa. Misure come questa possono funzionare solo se combinate con programmi di istruzione interni.

  • Creare procedure per l'individuazione:

    • Esaminare regolarmente i record DNS per assicurarsi che tutti i sottodomini siano mappati alle risorse di Azure che:

      • Exist : eseguire una query sulle zone DNS per le risorse che puntano ai sottodomini di Azure, ad esempio *.azurewebsites.net o *.cloudapp.azure.com (vedere l'elenco di riferimenti dei domini di Azure).
      • Si è proprietari: verificare di essere proprietari di tutte le risorse destinate ai sottodomini DNS.

    • Gestire un catalogo di servizi degli endpoint del nome di dominio completo (FQDN) di Azure e dei proprietari dell'applicazione. Per compilare il catalogo dei servizi, eseguire lo script di query di Azure Resource Graph seguente. Questo script proietta le informazioni sull'endpoint FQDN delle risorse a cui si ha accesso e le restituisce in un file CSV. Se si ha accesso a tutte le sottoscrizioni per il tenant, lo script considera tutte le sottoscrizioni come illustrato nello script di esempio seguente. Per limitare i risultati a un set specifico di sottoscrizioni, modificare lo script come illustrato.

  • Creare procedure per la correzione:

    • Quando vengono trovate voci DNS in sospeso, il team deve verificare se si è verificata una compromissione.
    • Esaminare il motivo per cui l'indirizzo non è stato reindirizzato quando la risorsa è stata rimossa.
    • Eliminare il record DNS se non è più in uso o puntare alla risorsa di Azure corretta (FQDN) di proprietà dell'organizzazione.

Pulire i puntatori DNS o ripetere l'attestazione del DNS

Dopo l'eliminazione della risorsa del servizio cloud classica, il DNS corrispondente è riservato in base ai criteri DNS di Azure. Durante il periodo di prenotazione, il riutilizzo del DNS non sarà consentito TRANNE per le sottoscrizioni appartenenti al tenant Microsoft Entra della sottoscrizione proprietaria originariamente del DNS. Dopo la scadenza della prenotazione, il DNS è gratuito per essere richiesto da qualsiasi sottoscrizione. Prendendo prenotazioni DNS, il cliente ha tempo per pulire qualsiasi associazione/puntatore a tale DNS o 2) ripetere l'attestazione del DNS in Azure. È consigliabile eliminare le voci DNS indesiderate al più presto. È possibile derivare il nome DNS riservato aggiungendo il nome del servizio cloud alla zona DNS per tale cloud.

  • Public - cloudapp.net
  • Mooncake - chinacloudapp.cn
  • Fairfax - usgovcloudapp.net
  • BlackForest - azurecloudapp.de

Ad esempio, un servizio ospitato in public denominato "test" avrebbe DNS "test.cloudapp.net"

Esempio: la sottoscrizione 'A' e la sottoscrizione 'B' sono le uniche sottoscrizioni appartenenti al tenant di Microsoft Entra 'AB'. La sottoscrizione 'A' contiene un servizio cloud classico 'test' con nome DNS 'test.cloudapp.net'. Dopo l'eliminazione del servizio cloud, viene eseguita una prenotazione sul nome DNS 'test.cloudapp.net'. Durante il periodo di prenotazione, solo la sottoscrizione 'A' o la sottoscrizione 'B' sarà in grado di richiedere il nome DNS 'test.cloudapp.net' creando un servizio cloud classico denominato 'test'. Nessun'altra sottoscrizione sarà autorizzata a richiederla. Dopo il periodo di prenotazione, qualsiasi sottoscrizione in Azure può ora richiedere "test.cloudapp.net".

Passaggi successivi

Per altre informazioni sui servizi correlati e sulle funzionalità di Azure che è possibile usare per difendersi dall'acquisizione di sottodominio, vedere le pagine seguenti.