Förhindra överflödiga DNS-poster och undvik underdomänövertagande

Den här artikeln beskriver det vanliga säkerhetshotet vid subdomänövertagande och de steg du kan vidta för att mildra det.

Vad är ett underdomänövertagande?

Subdomänövertaganden är ett vanligt, högallvarligt hot för organisationer som regelbundet skapar och tar bort många resurser. Ett övertagande av en underdomän kan inträffa när du har en DNS-post som pekar på en avetablerad Azure-resurs. Sådana DNS-poster kallas även "dangling DNS"-poster. CNAME-posterna är särskilt sårbara för detta hot. Underdomänövertaganden gör det möjligt för skadliga aktörer att omdirigera trafik som är avsedd för en organisations domän till en webbplats som utför skadlig aktivitet.

Ett vanligt scenario för ett underdomänövertagande:

  1. SKAPELSE:

    1. Du etablerar en Azure-resurs med ett fullständigt domännamn (FQDN) för app-contogreat-dev-001.azurewebsites.net.

    2. Du tilldelar en CNAME-post i DNS-zonen med underdomänen greatapp.contoso.com som dirigerar trafik till din Azure-resurs.

  2. AVAKTIVERING:

    1. Azure-resursen avaktiveras eller raderas efter att den inte längre behövs.

      Nu ska CNAME-posten greatapp.contoso.comtas bort från DNS-zonen. Om CNAME-posten inte tas bort annonseras den som en aktiv domän men dirigerar inte trafik till en aktiv Azure-resurs. Nu har du en "dangling" DNS-post.

    2. Dangling-underdomänen, greatapp.contoso.com, är nu sårbar och kan tas över genom att tilldelas till en annan Azure-prenumerationsresurs.

  3. ÖVERTAGANDE:

    1. Med hjälp av vanliga metoder och verktyg upptäcker en angripare den hängande underdomänen.

    2. Hotaktören etablerar en Azure-resurs med samma FQDN för den resurs som du tidigare kontrollerade. I det här exemplet . app-contogreat-dev-001.azurewebsites.net

    3. Trafik som skickas till subdomänen greatapp.contoso.com dirigeras nu till den illvilliga aktörens resurs där de kontrollerar innehållet.

Underdomän-övertagande från en avetablerad webbplats

Riskerna med underdomänövertagande

När en DNS-post pekar på en resurs som inte är tillgänglig bör själva posten tas bort från DNS-zonen. Om den inte tas bort är det en "dangling DNS"-post och skapar möjligheten till övertagande av underdomäner.

Dangling DNS-poster gör det möjligt för hotaktörer att ta kontroll över det associerade DNS-namnet för att vara värd för en skadlig webbplats eller tjänst. Skadliga sidor och tjänster i en organisations underdomän kan resultera i:

  • Förlust av kontroll över innehållet i subdomänen: Negativ publicitet om din organisations oförmåga att säkra sitt innehåll, varumärkesskada och förlorat förtroende.

  • Cookie-insamling från intet ont anande besökare: Det är vanligt att webbappar exponerar sessionscookies för subdomäner (*.contoso.com). Alla underdomäner kan komma åt dem. Hotaktörer kan använda subdomänövertagande för att bygga en autentisk sida, lura intet ont anande användare att besöka den och samla in deras cookies (även säkra cookies). En vanlig missuppfattning är att SSL-certifikat skyddar din webbplats och dina användares cookies från övertagande. En hotskådespelare kan dock använda den kapade underdomänen för att ansöka om och ta emot ett giltigt SSL-certifikat. Giltiga SSL-certifikat ger dem åtkomst till säkra cookies och kan ytterligare öka den skadliga webbplatsens upplevda legitimitet.

  • Nätfiskekampanjer: Illvilliga aktörer utnyttjar ofta autentiska subdomäner i nätfiskekampanjer. Risken omfattar både skadliga webbplatser och MX-register. MX-poster skulle kunna göra det möjligt för angripare att ta emot e-postmeddelanden som skickas till legitima underdomäner som är kopplade till betrodda varumärken.

  • Ytterligare risker: Skadliga sajter kan eskalera till andra klassiska attacker som XSS, CSRF, CORS-bypass och fler.

Identifiera obehäftade DNS-poster

Om du vill identifiera DNS-poster i din organisation som kan vara dinglande använder du Microsofts GitHub-värdbaserade PowerShell-verktyg "Get-DanglingDnsRecords".

Detta verktyg hjälper dig att lista alla domäner med en CNAME kopplad till en befintlig Azure-resurs som du skapat på dina prenumerationer eller hyresgäster.

Om dina CNAME-poster finns i andra DNS-tjänster och pekar på Azure-resurser, anger du CNAME-posterna i en indatafil med verktyget.

Verktyget stöder De Azure-resurser som anges i följande tabell. Verktyget extraherar, eller tar som indata, alla klientorganisationens CNAMEs.

Tjänst Typ FQDN-egenskap Exempel
Azure Front Door-tjänsten microsoft.network/frontdoors egenskaper.cNamn abc.azurefd.net
Azure Blob Storage (molnlagringstjänst) microsoft.storage/lagringskonton egenskaper.primäraÄndpunkter.blob abc.blob.core.windows.net
Azure CDN microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net
Offentliga IP-adresser microsoft.network/publicipaddresses properties.dnsInställningar.fqdn abc.EastUs.cloudapp.azure.com
Azure Traffic Manager microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.net
Azure Container Instance (en molnbaserad behållartjänst) microsoft.containerinstance/containergroups properties.ipAddress.fqdn abc.EastUs.azurecontainer.io
Azure API Management microsoft.apimanagement/service properties.hostnameConfigurations.hostName abc.azure-api.net
Azure App Service microsoft.web/sites egenskaper.standardvärdnamn abc.azurewebsites.net
Azure App Service – platser microsoft.web/sites/slots egenskaper.standardvärdnamn abc-def.azurewebsites.net

Förutsättningar

Kör frågan som en användare som har:

  • Åtminstone rollåtkomst Reader till Azure-prenumerationerna.
  • Läsbehörighet till Azure Resource Graph.

Om du är global administratör för din organisations hyresgäst, följ riktlinjerna i Elevate access för att hantera alla Azure-prenumerationer och hanteringsgrupper för att få tillgång till alla organisationens prenumerationer.

Tips

Överväg Azure Resource Graphs begränsningar för begärandefrekvens och gränser för sidindelning om du har en stor Azure-miljö.

Läs mer om hur du arbetar med stora Azure-resursdatauppsättningar.

Verktyget använder prenumerationsbatchbearbetning för att undvika dessa begränsningar.

Kör skriptet

För mer information om PowerShell-skriptet, se Get-DanglingDnsRecords.ps1.

Åtgärda särkopplade DNS-poster

Granska dina DNS-zoner och identifiera CNAME-poster som dinglar eller tas över. Om du hittar hängande eller övertagna subdomäner, ta bort de sårbara subdomänerna och minska riskerna genom att använda följande steg:

  1. Ta bort alla CNAME-poster från din DNS-zon som pekar på FQDN för resurser som inte längre tillhandahålls.

  2. För att dirigera trafik till resurser du kontrollerar, provisionera fler resurser med FQDN:erna som anges i CNAME-posterna för de hängande subdomänerna.

  3. Granska programkoden för referenser till specifika underdomäner och uppdatera eventuella felaktiga eller inaktuella underdomänreferenser.

  4. Undersök om någon kompromettering har skett och vidta åtgärder enligt organisationens incidenthanteringsrutiner. För tips och bästa praxis för undersökning:

    Om din applikationslogik leder till att hemligheter, såsom OAuth-uppgifter, skickas till hängande subdomäner eller om integritetskänslig information överförs till dessa subdomäner, kan denna data exponeras för tredje part.

  5. Förstå varför CNAME-posten inte togs bort från din DNS-zon när du avprovisionerade resursen och vidta åtgärder för att säkerställa att DNS-poster uppdateras korrekt när Azure-resurser avprovisioneras i framtiden.

Förhindra hängande DNS-poster

Se till att processer som förhindrar kvardröjande DNS-poster och de subdomänskapningar som de kan leda till blir en central del av ditt säkerhetsprogram.

Följande avsnitt beskriver Azure-tjänstefunktioner som kan hjälpa till att skapa förebyggande åtgärder. Etablera andra metoder för att förebygga detta problem genom organisationens bästa praxis eller standardrutiner.

Aktivera Microsoft Defender för App Service

Microsoft Defender för molnet integrerade molnplattform för arbetsbelastningsskydd (CWPP) erbjuder en rad planer för att skydda dina Azure-, hybrid- och multimolnsresurser och arbetsbelastningar.

Microsoft Defender för App Service-planen innehåller dinglande DNS-identifiering. När du aktiverar detta abonnemang får du säkerhetsvarningar om du avvecklar en App Service-webbplats men inte tar bort dess anpassade domän från din DNS-registrar.

Microsoft Defender för molnets skydd mot övergivna DNS-poster är tillgängligt oavsett om du hanterar dina domäner med Azure DNS eller en extern domänregistrator och gäller för App Service i både Windows och Linux.

För mer information om denna funktion och andra fördelar med dessa Microsoft Defender-planer, se Introduktion till Microsoft Defender för App Service.

Använda Azure DNS-aliasposter

Azure DNS-aliasposter kan förhindra hängande referenser genom att koppla livscykeln för en DNS-post till en Azure-resurs. Anta till exempel att en DNS-post som är kvalificerad som en aliaspost pekar på en offentlig IP-adress eller en Traffic Manager-profil. Om du tar bort de underliggande resurserna blir DNS-aliasposten en tom postuppsättning. DNS-aliasposten refererar inte längre till den borttagna resursen. Alias register har begränsningar för vad de kan skydda. Listan är för närvarande begränsad till:

  • Azure Front Door-tjänsten
  • profiler för Traffic Manager
  • Endpunkter för Azure Content Delivery Network (CDN)
  • Offentliga IP-adresser

Trots det begränsade tjänsteutbudet i dag bör du använda aliasposter för att skydda dig mot kapning av underdomäner när det är möjligt.

För mer information, se Azure DNS alias records capabilities.

Använda Verifiering av anpassad domän i Azure App Service

När du skapar DNS-poster för Azure App Service, skapa en asuid.{subdomain} TXT-post med domänverifierings-ID:t. När en sådan TXT-post finns kan ingen annan Azure-prenumeration validera den anpassade domänen eller ta över den.

Dessa poster hindrar inte att någon skapar en Azure App Service-instans med samma namn som anges i din CNAME-post. Utan möjlighet att bevisa äganderätten till domännamnet kan illasinnade aktörer inte ta emot trafik eller kontrollera innehållet.

För mer information, se Mappa ett befintligt anpassat DNS-namn till Azure App Service.

Skapa och automatisera processer för att minimera hotet

Utvecklare och driftteam bör köra rensningsprocesser för att undvika DNS-hot som hänger med i luften. Följande metoder hjälper din organisation att undvika detta hot.

  • Skapa procedurer för förebyggande:

    • Utbilda programutvecklare om att omdirigera adresser när de tar bort resurser.

    • Placera "Ta bort DNS-post" i listan över nödvändiga kontroller när du inaktiverar en tjänst.

      • Lägg till raderingslås på alla resurser som har en anpassad DNS-post. Ett borttagningslås fungerar som en indikator på att mappningen måste tas bort innan resursen avetableras. Åtgärder som dessa fungerar endast när de kombineras med interna utbildningsprogram.

  • Skapa procedurer för upptäckt:

    • Granska dina DNS-poster regelbundet för att se till att dina underdomäner är mappade till Azure-resurser som:

      • Exist: Sök i dina DNS-zoner efter resurser som pekar på Azure subdomäner som *.azurewebsites.net eller *.cloudapp.azure. com (se referenslistan över Azure-domäner).
      • Du äger: Bekräfta att du äger alla resurser som dina DNS-subdomäner riktar sig mot.

    • Underhålla en tjänstkatalog med dina FQDN-slutpunkter i Azure och programägare. Använd Azure Resource Graph, Azure-portalen eller en annan process för tillgångsinventering för att regelbundet exportera FQDN-endpointinformationen för resurser du kan komma åt. Om du har åtkomst till alla prenumerationer i din klientorganisation, ta med alla prenumerationer i inventeringen. Om du inte gör det, dokumentera vilka prenumerationer inventariet täcker.

  • Skapa procedurer för reparation:

    • När ditt team hittar hängande DNS-poster, undersök om någon kompromettering har inträffat.
    • Undersök varför adressen inte omdirigerades när resursen inaktiverades.
    • Ta bort DNS-posten om den inte längre används eller peka den på rätt Azure-resurs (FQDN) som ägs av din organisation.

Rensa DNS-pekare eller återta DNS

När du raderar en klassisk molntjänstresurs reserverar Azure motsvarande DNS-namn enligt Azure DNS-policys. Under reservationsperioden kan endast prenumerationer som tillhör Microsoft Entra-tenanten för prenumerationen som ursprungligen ägde DNS-namnet återanvända det. Efter att reservationen löper ut kan vilken Azure-prenumeration som helst göra anspråk på DNS-namnet. DNS-reservationer ger dig tid att rensa associationer eller pekare till DNS-namnet, eller att återta DNS-namnet i Azure. Radera oönskade DNS-poster så snart som möjligt. Du kan härleda det reserverade DNS-namnet genom att lägga till molntjänstens namn i DNS-zonen för det molnet.

  • Offentlig: cloudapp.net
  • Mooncake: chinacloudapp.cn
  • Fairfax: usgovcloudapp.net
  • BlackForest: azurecloudapp.de

Till exempel har en hostad tjänst i Public named test DNS-namnet test.cloudapp.net.

Exempel: Prenumerationer A och B är de enda prenumerationerna som tillhör Microsoft Entra-tenantenAB. Prenumerationen A innehåller en klassisk molntjänst med namnet test DNS test.cloudapp.net. När du tar bort molntjänsten reserverar Azure DNS-namnet test.cloudapp.net. Under reservationsperioden kan endast prenumeration A eller prenumeration B göra anspråk på DNS-namnet test.cloudapp.net genom att skapa en klassisk molntjänst vid namn test. Inga andra prenumerationer kan göra anspråk på det. Efter reservationsperioden kan vilken Azure-prenumeration som helst göra anspråk på test.cloudapp.net.

Nästa steg

Mer information om relaterade tjänster och Azure-funktioner som du kan använda för att försvara dig mot övertagande av underdomäner finns på följande sidor.

  • Last updated on