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 genoverdredet. Kløften mellem "DNS-record eksisterer" og "ressource eksisterer stadig" er hvor subdomain-overtagelse lever.

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 dette er værre 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.

Indholdsindjektion og brandskade. En angriber kan betjene hvad som helst under dit underdomæne — defacement, malware, spam. Alt attributeret 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 du 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.

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 attack surface 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.

Se platformen Book demo