Jeres team afviklede en cloudtjeneste for seks måneder siden og slettede ressourcen. Men ingen fjernede DNS-recorden. Det underdomæne resolver stadig — og hvem som helst kan nu gøre krav på den underliggende infrastruktur og betjene indhold under dit domæne. Dette er subdomain-overtagelse, og det er mere almindeligt end de fleste organisationer indser.

Dangling DNS — undertiden kaldet en dangling CNAME eller dangling delegation — beskriver en DNS-record der peger på en ressource der ikke længere eksisterer. DNS-posten er live og resolver, men målet i den anden ende er slettet, udløbet eller genoverdraget. Kløften mellem "DNS-record eksisterer" og "ressource eksisterer stadig" er hvor subdomain-overtagelse lever. Se vores artikel om angribere der kortlægger infrastruktur via certifikater for den bredere kontekst om hvordan disse sårbarheder opdages og udnyttes.

Hvordan subdomain-overtagelse fungerer

  1. En organisation opretter en cloudressource — en Azure Static Web App, en AWS S3-bucket, et GitHub Pages-site, en Heroku-app, et Fastly CDN-endpoint — og peger et underdomæne på den via en CNAME-record.
  2. Ressourcen slettes når projektet slutter, tjenesten migreres eller hostingkontrakten udløber. Cloududbyderen frigiver ressourcenavnet.
  3. CNAME-recorden fjernes ikke. Den peger stadig på det gamle ressourcenavn.
  4. En angriber registrerer det samme ressourcenavn på den samme platform. På mange cloudtjenester allokeres ressourcenavne på first-come-first-served basis.
  5. Angriberen kontrollerer nu hvad der betjenes under dit underdomæne. Besøgende på staging.ditdomæne.dk ser nu indhold kontrolleret af en tredjepart — men adresselinjen viser dit domæne.

Hvorfor subdomain-overtagelse er mere alvorligt end det lyder

Cookie-tyveri. Cookies scoped til .ditdomæne.dk sendes af browseren til alle underdomæner, inklusiv det overtagne. En angriber der betjener indhold under dit underdomæne kan modtage session-cookies fra brugere der besøger siden.

Credential-phishing. Et overtaget underdomæne er ideelt til phishing. Adresselinjen viser dit domæne. Brugere har ingen indlysende grund til at være mistænksomme.

Indholdsinjektion og brandskade. En angriber kan betjene hvad som helst under dit underdomæne — defacement, malware, spam. Alt attribueret til din organisation.

OAuth og SSO-misbrug. Nogle identitetsudbydere tillader redirect URI'er scoped til et domæne — dvs. ethvert underdomæne er et gyldigt redirect-mål. Et overtaget underdomæne kan bruges som redirect-destination i OAuth-flows.

Sådan opdager og afhjælper I dangling DNS

Trin 1 — Byg en komplet underdomæneliste. Brug CT-logs til at opregne hvert underdomæne der nogensinde har haft et certifikat under dit domæne. Dangling poster stammer ofte fra skygge-IT som intet team formelt ejede.

Trin 2 — Resolver alle underdomæner. Kontroller nuværende DNS-opløsning. Kig specifikt efter CNAME-records — disse er de farlige, fordi de delegerer opløsning til et tredjepartsnavnerum.

Trin 3 — Tjek CNAME-mål. For hver CNAME, kontroller om målressourcen stadig eksisterer. En CNAME der peger på et platform der returnerer "no such site" indikerer at ressourcen er slettet mens CNAME'en forblev.

Trin 4 — Afhjælp øjeblikkeligt. Enhver bekræftet dangling CNAME skal fjernes fra DNS øjeblikkeligt.

Trin 5 — Etabler en proces for fremtidig afvikling. Rodårsagen er en afviklingsproces der ikke inkluderer DNS-oprydning. Løsningen er proceduremæssig: hver gang en cloudressource med en brugerdefineret DNS-record slettes, skal DNS-recorden fjernes som en del af den samme opgave.

Forebyggelse er enklere end detektion

  • Infrastructure-as-Code. Når DNS-records styres sammen med de ressourcer de peger på i samme IaC-konfiguration, sletter sletning af ressourcen automatisk DNS-recorden.
  • Auditér DNS regelmæssigt mod live ressourcer. En periodisk gennemgang af alle CNAME-records for at kontrollere at hvert mål stadig eksisterer, fanger poster der slap igennem afviklingsprocessen.

Hvordan CertControl viser dangling DNS

CertControls eksterne angrebsoverflade scanner kombinerer CT-log-enumeration med aktiv DNS-opløsning og CNAME-kædeanalyse for at vise potentielle dangling poster som en del af sin regelmæssige opdagelsesproces. Når scanneren finder et underdomæne der resolver via CNAME til en ekstern platform, kontrollerer den om målressourcen ser ud til at eksistere — og markerer poster hvor CNAME-kæden fører til et platform-svar der tyder på at ressourcen er slettet.

Ofte stillede spørgsmål

Hvad er dangling DNS?

Det er en DNS-record — ofte en CNAME — der stadig resolver, men peger på en cloudressource der er slettet, udløbet eller genoverdraget. Kløften mellem den live record og den manglende ressource er hvor subdomain-overtagelse bliver mulig.

Hvordan sker subdomain-overtagelse?

En cloudressource slettes, men dens CNAME efterlades. En angriber registrerer det samme ressourcenavn på samme platform, hvor navne er first-come-first-served, og kontrollerer derefter hvad der betjenes under jeres underdomæne.

Hvorfor er subdomain-overtagelse farligt?

Et overtaget underdomæne kan stjæle domæne-scopede cookies, hoste overbevisende phishing på jeres rigtige domæne, injicere indhold, omgå Content Security Policy-allowlists og misbruge OAuth- eller SSO-redirects.

Hvordan hjælper Certificate Transparency-logs med at opdage dangling DNS?

CT-logs viser hvert underdomæne der nogensinde har haft et certifikat. Ved at resolvere hvert og kontrollere om CNAME-målet stadig eksisterer krydsrefereres certifikathistorik mod nuværende DNS-tilstand for at finde forældreløse poster.

Hvordan forebygger jeg dangling DNS?

Styr DNS-records som Infrastructure-as-Code så sletning af en ressource fjerner dens record, hold TTL'er korte, auditér CNAME-mål regelmæssigt, og gør DNS-oprydning til et obligatorisk trin i enhver afviklingsproces.

Se platformen Book demo