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 sottodominio sono una minaccia comune e con gravità elevata per le organizzazioni che creano regolarmente ed eliminano molte risorse. Un'acquisizione di sottodominio può verificarsi quando si dispone di un record DNS che punta a una risorsa di Azure 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 greatapp.contoso.comCNAME deve 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 "dangling".

    2. Il sottodominio dangling, greatapp.contoso.com, è ora vulnerabile e può essere assunto tramite l'assegnazione a una risorsa di un'altra sottoscrizione di Azure.

  3. ACQUISIZIONE:

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

    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 deve essere rimosso dalla zona DNS. Se non viene eliminato, si tratta di un record "DNS incerto" 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 di posta elettronica 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 incerte

Per identificare le voci DNS all'interno dell'organizzazione che potrebbero essere incerte, 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 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.dns Impostazioni.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 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 Amministrazione istrator 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 Di Azure 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.ps1 e 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 che sono incerti 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 l'instradamento del traffico alle risorse nel controllo, effettuare il provisioning di più risorse con i nomi di dominio completi specificati nei record CNAME dei sottodomini dangling.

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

  4. Verificare se si è verificata una compromissione e intervenire in base alle procedure di risposta agli eventi imprevisti 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 perché il record CNAME non è stato rimosso dalla zona DNS quando la risorsa è stata sottoposta a deprovisioning ed eseguire le operazioni necessarie per assicurarsi che i record DNS vengano aggiornati in modo appropriato quando le risorse di Azure vengono deprovisionate in futuro.

Impedire voci DNS incerte

Assicurarsi che l'organizzazione abbia implementato processi per impedire voci DNS incerte e che le acquisizioni di sottodominio 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 servizio app

la piattaforma CWPP (Cloud Workload Protection Platform) integrata di Microsoft Defender per il 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 servizio app include il rilevamento DNS incerto. Con questo piano abilitato, si riceveranno avvisi di sicurezza se si rimuove un sito Web servizio app ma non si rimuove il dominio personalizzato dal registrar DNS.

Microsoft Defender per il cloud la protezione DNS incerta è disponibile se i domini vengono gestiti con DNS di Azure o con un registrar di dominio esterno e si applicano a 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 servizio app.

Usare i record alias DNS di Azure

I record alias di DNS di Azure possono impedire riferimenti incerti associando 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 di azure rete per la distribuzione di contenuti (rete CDN)
  • 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 Azure

Quando si creano voci DNS per app Azure Servizio, 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 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 a app Azure Servizio.

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 incerte. 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 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 incerte, 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. Il nome DNS riservato può essere derivato aggiungendo il nome del servizio cloud alla zona DNS per tale cloud.

  • Pubblico - 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.