Condividi tramite

Evitare voci DNS inesatte ed evitare l'acquisizione di sottodomini

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. Questi 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 assumerne il controllo assegnandolo a una risorsa di una sottoscrizione di Azure.

  3. INSEDIAMENTO:

    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.

Presa di controllo di un sottodominio da un sito Web disattivato

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.

Le voci DNS in sospeso possono consentire ad attori malintenzionati di prendere 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 la presa di controllo di un sottodominio per creare una pagina dall'aspetto autentico, ingannare gli utenti insospettabili a visitarla e raccogliere i loro cookie, compresi quelli sicuri. Un malinteso comune è che l'uso dei certificati SSL protegge il sito e i cookie degli utenti da un'acquisizione. Tuttavia, un attore malevolo può usare il sottodominio dirottato 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.

Servizio Tipo FQDNproprietà Esempio
Frontdoor di Azure microsoft.network/frontdoors proprietà.cName abc.azurefd.net
Archiviazione BLOB di Azure microsoft.storage/storageaccounts proprietà.primaryEndpoints.blob abc.blob.core.windows.net
Rete CDN di Azure microsoft.cdn/profiles/endpoints proprietà.hostName abc.azureedge.net
Indirizzi IP pubblici Indirizzo IP pubblico di Microsoft: microsoft.network/publicipaddresses proprietà.dnsSettings.fqdn abc.EastUs.cloudapp.azure.com
Gestione traffico di Azure microsoft.network/trafficmanagerprofiles proprietà.dnsConfig.fqdn abc.trafficmanager.net
Istanza di contenitore di Azure microsoft.containerinstance/containergroups proprietà.ipAddress.fqdn abc.EastUs.azurecontainer.io
Gestione API di Azure microsoft.apimanagement/service proprietà.hostnameConfigurations.hostName abc.azure-api.net
Servizio app di Azure microsoft.web/sites proprietà.defaultHostName abc.azurewebsites.net
Servizio app di Azure - Slot microsoft.web/sites/slots proprietà.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 richieste 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 DNS in sospeso

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

  1. Rimuovere dalla zona DNS 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.

Prevenire voci DNS in sospeso

Assicurarsi che l'organizzazione abbia implementato processi per evitare voci DNS orfane o non collegate e prevenire le conseguenti acquisizioni di sottodomini è una parte cruciale del vostro 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. Per esempio, consideri un record DNS qualificato come record alias per puntare a un indirizzo IP pubblico o a un profilo di Traffic Manager. 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 del 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 record TXT asuid.{sottodominio} 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 o prenderne il controllo.

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.

Scopri di più 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.

    • Aggiungere "Rimuovi voce DNS" all'elenco dei controlli necessari durante la dismissione di un servizio.

    • Inserire blocchi di eliminazione su qualsiasi risorsa con una voce DNS personalizzata. Un blocco di eliminazione funge da indicatore che la mappatura deve essere rimossa prima del disapprovvigionamento 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.

    • Mantenere un catalogo di servizi degli endpoint del 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 indagare per vedere 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 indirizzarlo verso la risorsa di Azure corretta (FQDN) appartenente alla tua 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, eccetto per le sottoscrizioni appartenenti al tenant Microsoft Entra della sottoscrizione che possedeva originariamente il DNS. Dopo la scadenza della prenotazione, il DNS è gratuito per essere richiesto da qualsiasi sottoscrizione. Facendo prenotazioni DNS, il cliente ha tempo per 1) pulire qualsiasi associazione/puntatore a tale DNS o 2) recuperare il 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.

  • Pubblico - cloudapp.net
  • Torta della luna - chinacloudapp.cn
  • Fairfax - usgovcloudapp.net
  • Foresta Nera - 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 altro abbonamento sarà autorizzato a richiederlo. 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.