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

  • Artikel

Den här artikeln beskriver det vanliga säkerhetshotet vid övertagande av underdomäner och vilka åtgärder du kan vidta för att minimera problemet.

Vad är ett underdomänövertagande?

Underdomänövertaganden är ett vanligt hot med hög allvarlighetsgrad för organisationer som regelbundet skapar och tar bort många resurser. Ett övertagande av underdomäner kan inträffa när du har en DNS-post som pekar på en avetablerade Azure-resurs. Sådana DNS-poster kallas även "dinglande DNS"-poster. CNAME-poster är särskilt sårbara för det här hotet. 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. SKAPANDET:

    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. AVETABLERING:

    1. Azure-resursen avetableras eller tas bort när 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 identifierar en hotskådespelare dangling-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 underdomänen greatapp.contoso.com dirigeras nu till den skadliga aktörens resurs där de kontrollerar innehållet.

Underdomänövertagande från en avetablerade 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 underdomänen – Negativ press om organisationens oförmåga att skydda sitt innehåll, varumärkesskador och förlust av förtroende.

  • Cookieskörd från intet ont anande besökare – Det är vanligt att webbappar exponerar sessionscookies för underdomäner (*.contoso.com). Alla underdomäner kan komma åt dem. Hotaktörer kan använda underdomänövertagande för att skapa en autentisk sida, lura intet ont anande användare att besöka den och skörda sina cookies (till och med säkra cookies). En vanlig missuppfattning är att användning av SSL-certifikat skyddar din webbplats och användarnas cookies från ett ö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 – Skadliga aktörer utnyttjar ofta autentiska underdomäner i nätfiskekampanjer. Risken omfattar både skadliga webbplatser och MX-poster, vilket kan göra det möjligt för hotaktörer att ta emot e-postmeddelanden riktade till legitima underdomäner som är associerade med betrodda varumärken.

  • Ytterligare risker – Skadliga webbplatser kan användas för att eskalera till andra klassiska attacker som XSS, CSRF, CORS bypass med mera.

Identifiera dinglande 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".

Det här verktyget hjälper Azure-kunder att lista alla domäner med ett CNAME som är associerat med en befintlig Azure-resurs som har skapats i deras prenumerationer eller klientorganisationer.

Om dina CNAME-poster finns i andra DNS-tjänster och pekar på Azure-resurser anger du CNAMEs i en indatafil till 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 FQDNproperty Exempel
Azure Front Door microsoft.network/frontdoors properties.cName abc.azurefd.net
Azure Blob Storage microsoft.storage/storageaccounts properties.primaryEndpoints.blob abc.blob.core.windows.net
Azure CDN microsoft.cdn/profiles/endpoints properties.hostName abc.azureedge.net
Offentliga IP-adresser microsoft.network/publicipaddresses properties.dns Inställningar.fqdn abc.EastUs.cloudapp.azure.com
Azure Traffic Manager microsoft.network/trafficmanagerprofiles properties.dnsConfig.fqdn abc.trafficmanager.net
Azure Container Instance 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 properties.defaultHostName abc.azurewebsites.net
Azure App Service – fack microsoft.web/sites/slots properties.defaultHostName abc-def.azurewebsites.net

Förutsättningar

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

  • åtkomst på minst läsarnivå till Azure-prenumerationer
  • läsa åtkomst till Azure-resursdiagram

Om du är global administratör för organisationens klientorganisation följer du vägledningen i Utöka åtkomst för att hantera alla Azure-prenumerationer och hanteringsgrupper för att få åtkomst till alla din organisations prenumerationer

Dricks

Azure Resource Graph har begränsningar för begränsning och växling som du bör överväga 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

Läs mer om PowerShell-skriptet Get-DanglingDnsRecords.ps1 och ladda ned det från GitHub: https://aka.ms/Get-DanglingDnsRecords.

Åtgärda dinglande DNS-poster

Granska dina DNS-zoner och identifiera CNAME-poster som dinglar eller tas över. Om underdomäner visar sig vara dinglande eller har tagits över tar du bort de sårbara underdomänerna och minskar riskerna med följande steg:

  1. Ta bort alla CNAME-poster som pekar på FQDN för resurser som inte längre har etablerats från DNS-zonen.

  2. Om du vill att trafik ska dirigeras till resurser i din kontroll etablerar du fler resurser med de FQDN:er som anges i CNAME-posterna för dangling-underdomänerna.

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

  4. Undersöka om någon kompromiss har inträffat och vidta åtgärder enligt organisationens procedurer för incidenthantering. Tips och metodtips för att undersöka:

    Om din programlogik resulterar i hemligheter, till exempel OAuth-autentiseringsuppgifter, skickas till dangling-underdomäner eller om sekretesskänslig information överförs till dessa underdomäner, finns det en möjlighet att dessa data exponeras för tredje part.

  5. Förstå varför CNAME-posten inte togs bort från DNS-zonen när resursen avetablerades och vidta åtgärder för att se till att DNS-posterna uppdateras korrekt när Azure-resurser avetableras i framtiden.

Förhindra dangling DNS-poster

Att se till att din organisation har implementerat processer för att förhindra dinglande DNS-poster och resulterande underdomänövertaganden är en viktig del av ditt säkerhetsprogram.

Vissa Azure-tjänster erbjuder funktioner som hjälper dig att skapa förebyggande åtgärder och beskrivs nedan. Andra metoder för att förhindra det här problemet måste upprättas via organisationens metodtips 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. Med den här planen aktiverad får du säkerhetsaviseringar om du inaktiverar en App Service-webbplats men inte tar bort dess anpassade domän från DNS-registratorn.

Microsoft Defender för molnet dinglande DNS-skydd är tillgängligt oavsett om dina domäner hanteras med Azure DNS eller en extern domänregistrator och gäller för App Service i både Windows och Linux.

Läs mer om detta och andra fördelar med dessa Microsoft Defender-planer i Introduktion till Microsoft Defender för App Service.

Använda Azure DNS-aliasposter

Azure DNS:s aliasposter kan förhindra dinglande referenser genom att koppla livscykeln för en DNS-post med 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. Den refererar inte längre till den borttagna resursen. Observera att det finns gränser för vad du kan skydda med aliasposter. Idag är listan begränsad till:

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

Trots de begränsade tjänsteerbjudandena idag rekommenderar vi att du använder aliasposter för att försvara dig mot underdomänövertagande när det är möjligt.

Läs mer om funktionerna i Azure DNS:s aliasposter.

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

När du skapar DNS-poster för Azure App Service skapar du ett asuid. {underdomän} TXT-post med domänverifierings-ID. När en sådan TXT-post finns kan ingen annan Azure-prenumeration verifiera den anpassade domänen, dvs. ta över den.

Dessa poster hindrar inte någon från att skapa Azure App Service med samma namn som i din CNAME-post. Utan möjligheten att bevisa ägarskap för domännamnet kan hotaktörer inte ta emot trafik eller kontrollera innehållet.

Läs mer om hur du mappar ett befintligt anpassat DNS-namn till Azure App Service.

Skapa och automatisera processer för att minimera hotet

Det är ofta upp till utvecklare och driftteam att köra rensningsprocesser för att undvika dinglande DNS-hot. Metoderna nedan hjälper till att se till att din organisation undviker att drabbas av det här hotet.

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

    • Placera borttagningslå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 detta kan bara fungera i kombination med interna utbildningsprogram.

  • Skapa procedurer för identifiering:

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

      • Finns – Fråga dina DNS-zoner efter resurser som pekar på Azure-underdomäner som *.azurewebsites.net eller *.cloudapp.azure.com (se referenslistan över Azure-domäner).
      • Du äger – Bekräfta att du äger alla resurser som dns-underdomänerna är inriktade på.

    • Underhålla en tjänstkatalog med dina Fullständiga domännamnsslutpunkter (FQDN) i Azure och programägare. Skapa tjänstkatalogen genom att köra följande Azure Resource Graph-frågeskript. Det här skriptet projicerar FQDN-slutpunktsinformationen för de resurser som du har åtkomst till och matar ut dem i en CSV-fil. Om du har åtkomst till alla prenumerationer för din klientorganisation tar skriptet hänsyn till alla dessa prenumerationer enligt följande exempelskript. Om du vill begränsa resultatet till en specifik uppsättning prenumerationer redigerar du skriptet som det visas.

  • Skapa procedurer för reparation:

    • När dinglande DNS-poster hittas måste ditt team undersöka om någon kompromiss 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 gör anspråk på DNS igen

När den klassiska molntjänstresursen tas bort reserveras motsvarande DNS enligt Azure DNS-principer. Under reservationsperioden kommer återanvändning av DNS att förbjudas FÖRUTOM för prenumerationer som tillhör Microsoft Entra-klientorganisationen för den prenumeration som ursprungligen äger DNS. När reservationen har upphört att gälla kan DNS begäras av alla prenumerationer. Genom att ta DNS-reservationer får kunden lite tid att antingen 1) rensa eventuella associationer/pekare till nämnda DNS eller 2) återanvända DNS i Azure. Rekommendationen är att ta bort oönskade DNS-poster tidigast. Dns-namnet som reserveras kan härledas genom att molntjänstnamnet läggs till i DNS-zonen för molnet.

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

Till exempel skulle en värdbaserad tjänst i offentlig med namnet "test" ha DNS "test.cloudapp.net"

Exempel: Prenumerationen "A" och prenumerationen "B" är de enda prenumerationerna som tillhör Microsoft Entra-klientorganisationen "AB". Prenumerationen "A" innehåller en klassisk molntjänst "test" med DNS-namnet "test.cloudapp.net". När molntjänsten tas bort görs en reservation med DNS-namnet "test.cloudapp.net". Under reservationsperioden kan endast prenumerationen "A" eller prenumerationen "B" göra anspråk på DNS-namnet "test.cloudapp.net" genom att skapa en klassisk molntjänst med namnet "test". Inga andra prenumerationer kommer att tillåtas att göra anspråk på det. Efter reservationsperioden kan alla prenumerationer i Azure nu 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.