Subdomain takeover – finn og fjern hengende DNS-poster

Subdomain takeover kan oppstå når et navn som kampanje.bedrift.no fortsatt peker til en ekstern sky- eller publiseringstjeneste etter at virksomhetens ressurs er slettet eller løsrevet. Hvis plattformen lar en annen konto kreve det gamle ressursnavnet eller knytte til seg subdomenet, kan den nye kontoen få kontroll over innholdet som vises på virksomhetens adresse.

En død CNAME-post er likevel ikke automatisk en sårbarhet. For et reelt takeover-scenario må flere forhold være oppfylt. Undersøk derfor DNS, ressursstatus, domenebinding og leverandørens beskyttelse før dere konkluderer.

Hva må være sant for at takeover skal være mulig?

Den vanligste beviskjeden er:

1. Virksomheten publiserer en DNS-post for et subdomene.
2. Posten peker til en ekstern ressurs eller tjeneste.
3. Den opprinnelige ressursen er slettet, utløpt eller ikke lenger bundet til virksomhetens konto.
4. Leverandøren lar en annen konto opprette samme ressursnavn eller godta domenebindingen.
5. Trafikken fra virksomhetens subdomene når den nye kontrollerte ressursen.

Hvis plattformen krever en vedvarende domeneverifisering som bare virksomheten kan levere, reserverer navnet til opprinnelig tenant eller gjør ressursidentifikatoren globalt unik, kan DNS-posten være hengende uten at andre kan overta den.

Microsofts dokumentasjon om hengende DNS viser det klassiske forløpet: en CNAME blir stående etter at Azure-ressursen er slettet, og en annen konto kan i utsatte tjenestemodeller opprette en ressurs med det gamle målnavnet. Microsoft dokumenterer samtidig egne beskyttelser som verifikasjons-ID, tenantbundet gjenbruk og unike standardnavn. Risikoen må derfor vurderes for den konkrete tjenesten og konfigurasjonen.

Hengende DNS er årsaken, takeover er konsekvensen

Begrepene blandes ofte:

• Hengende DNS-post: DNS peker til en tjeneste, adresse eller delegering som ikke lenger har den forventede ressursen.
• Krevbar ressurs: En annen konto kan registrere eller binde målet.
• Subdomain takeover: En annen part har faktisk fått kontroll over tjenesten som virksomhetens subdomene peker til.

Et automatisk verktøy kan finne det første og gjette på det andre. Bare tjenesteeierskap og leverandørens faktiske kontrollmodell avgjør om risikoen er reell.

Hvilke DNS-poster kan bli hengende?

CNAME

Dette er den vanligste varianten:

kampanje.bedrift.no.  CNAME  prosjekt.plattform.example.

Hvis prosjekt.plattform.example ikke lenger tilhører virksomheten og plattformen lar navnet registreres på nytt, kan CNAME-posten sende trafikk til en ny eier.

A og AAAA

En A- eller AAAA-post kan peke til en skyadresse som senere frigis og tildeles en annen kunde. Ny eier av IP-adressen får ikke nødvendigvis automatisk riktig vertsnavn eller TLS, men trafikk kan nå systemet og eksponere feil tillit eller dataflyt.

NS-delegering

En NS-post kan delegere hele prosjekt.bedrift.no til eksterne navnetjenere. Hvis DNS-sonen eller leverandørkontoen forsvinner og kan opprettes av andre, kan konsekvensen bli kontroll over alle navn under delegeringen, ikke bare én webside.

MX og andre tjenesteposter

Gamle MX-, SRV- eller tjenesteposter kan sende e-post eller applikasjonstrafikk til en frigitt tjeneste. Dette omtales ikke alltid som klassisk subdomain takeover, men livsløpsfeilen og behovet for opprydding er det samme.

Hvorfor er et overtatt subdomene alvorlig?

Troverdig innhold og phishing

Adressen ligger under virksomhetens eget domene. En angriper kan derfor publisere en troverdig innloggingsside, falsk kampanje eller skadelig nedlasting på et navn kunder allerede forbinder med virksomheten.

For brede cookies

En host-only-cookie sendes bare til verten som satte den. En cookie med Domain=bedrift.no kan derimot sendes til flere subdomener. Hvis den inneholder en brukbar økt eller annen sensitiv verdi, kan et overtatt subdomene få tilgang til den.

Gå gjennom cookie-scope, SameSite, Secure og HttpOnly. Prefixet __Host- krever blant annet at Domain ikke settes og kan redusere eksponeringen mot søsken-subdomener når det brukes riktig.

Tillit i CSP, CORS og integrasjoner

Applikasjoner kan stole på mønstre som *.bedrift.no i Content Security Policy, CORS, OAuth redirect URI-er, SSO, webhooks eller API-tillatelseslister. Et overtatt navn kan da få mer tilgang enn en tilfeldig ekstern side.

Gyldig HTTPS er mulig

Hvis angriperen kan vise domenekontroll gjennom den overtatte tjenesten, kan en offentlig CA i enkelte scenarioer utstede et gyldig sertifikat. HTTPS viser da at forbindelsen går til noen som kontrollerer subdomenet – ikke at virksomheten fortsatt gjør det.

Bruk Certificate Transparency-overvåking som et signal, men ikke som eneste inventar.

Finn subdomener virksomheten faktisk publiserer

Start med kilder dere kontrollerer:

• eksport av autoritativ DNS-sone
• infrastructure as code og deploykonfigurasjon
• hosting-, CDN- og skyressurser
• sertifikat- og Certificate Transparency-oversikt
• omdirigeringslister og webserverkonfigurasjon
• prosjekt-, kampanje- og leverandørregister
• historiske soner etter oppkjøp eller leverandørbytte

Knytt hvert navn til:

Et navn uten eier eller utløpsdato er et funn selv om ressursen fortsatt virker.

Undersøk DNS-kjeden

Spør den aktuelle posttypen og følg eventuelle aliaser:

dig kampanje.bedrift.no CNAME +short
dig kampanje.bedrift.no A +short
dig kampanje.bedrift.no AAAA +short
dig kampanje.bedrift.no NS +short
dig kampanje.bedrift.no MX +short

Kontroller deretter målet direkte og sammenlign svar fra autoritative navnetjenere. Et rekursivt svar kan være gammelt til TTL utløper.

Se etter:

• mål som returnerer NXDOMAIN
• plattformmål som svarer, men viser «ukjent prosjekt» eller tilsvarende
• IP-adresser som ikke finnes i virksomhetens skyinventar
• delegerte navnetjenere uten en aktiv sone virksomheten eier
• wildcard-DNS som får vilkårlige navn til å treffe samme plattform
• poster opprettet i et annet DNS-panel enn de aktive navnetjenerne bruker

NXDOMAIN på målet viser at kjeden er brutt. Det beviser ikke at navnet kan kreves av andre.

Bekreft eierskap uten å prøve et angrep

Den tryggeste valideringen er defensiv og kontobasert:

1. Finn ressursen i virksomhetens eller leverandørens konto.
2. Bekreft at custom-domain-bindingen fortsatt står på riktig ressurs.
3. Kontroller plattformens dokumenterte verifikasjonsmekanisme.
4. Undersøk om ressursnavn er tenantbundet, reservert eller globalt gjenbrukbart.
5. Be plattformens support bekrefte status hvis dokumentasjonen ikke er entydig.
6. Fjern eller sett om DNS hvis virksomheten ikke lenger trenger navnet.

Ikke opprett en ressurs i en konto dere ikke har rett til å bruke, last opp en «proof»-fil, bestill sertifikat eller publiser innhold for å demonstrere takeover. Det kan påvirke brukere og gå fra sikkerhetskontroll til uautorisert handling.

OWASPs testguide skiller mellom oppdagelse, automatiske fingeravtrykk og manuell validering. I virksomhetens egen drift kan den siste delen gjøres gjennom konto, ressursregister og leverandørbekreftelse uten å forsøke å overta målet.

Automatiske funn er hypoteser

Skannere bruker ofte kjente feilmeldinger fra plattformer. De kan gi:

• falske positiver når leverandøren har endret domenebeskyttelsen
• falske negativer når feilsiden eller språket er endret
• feil klassifisering bak CDN, proxy eller egen feilhåndtering
• gamle treff fra DNS-cache
• manglende forståelse av tenant, custom-domain-verifisering eller soft delete

Bruk skanning til prioritering. Godkjenn ikke et sikkerhetsfunn før DNS-mål, ressursstatus og kravbarhet er undersøkt.

Slik håndterer dere et mistenkt hengende navn

Når navnet ikke lenger skal brukes

1. Bevar DNS-svar, tidspunkt og relevant konfigurasjon som dokumentasjon.
2. Kontroller at ingen aktiv tjeneste, e-post, OAuth-flyt eller lenke trenger navnet.
3. Fjern DNS-posten eller pek den midlertidig til en kontrollert, nøytral tjeneste.
4. Vent ut gammel TTL og kontroller autoritative og rekursive svar.
5. Fjern custom-domain-binding og leverandørressurs når trafikken ikke lenger peker dit.
6. Fjern navnet fra sertifikater, tillatelseslister, cookies, CSP, CORS og dokumentasjon.
7. Overvåk CT og DNS for uventet aktivitet etterpå.

Når tjenesten fortsatt trengs

Gjenopprett eller bind navnet til en ressurs virksomheten kontrollerer, og bruk plattformens domeneverifisering. Ikke slett DNS først hvis det skaper uakseptabel nedetid; sett opp et kontrollert erstatningsmål og flytt trafikken med en plan.

Når takeover kan ha skjedd

Behandle saken som en sikkerhetshendelse:

• fjern eller nøytraliser DNS-rutingen
• kontakt plattformen gjennom verifisert supportkanal
• sikre DNS-, sky- og registrar-kontoer
• bevar logger, HTTP-svar, CT-data og tidslinje
• undersøk hvilket innhold som ble levert og hvor lenge
• se etter eksponerte cookies, OAuth-koder, webhooks, skjema og e-post
• tilbakekall og roter berørte tokens, nøkler og økter
• vurder varsling til kunder og myndigheter ut fra faktisk konsekvens

Å slette DNS begrenser ny trafikk, men cache kan fortsette å sende brukere til det gamle målet til TTL utløper.

Riktig avviklingsrekkefølge

Takeover-risiko oppstår ofte fordi skyressursen slettes først og DNS behandles senere. Bruk denne rekkefølgen ved planlagt avvikling:

1. Finn eier, avhengigheter, CNAME-mål og gammel TTL.
2. Senk TTL minst én gammel TTL-periode før planlagt endring når det er nødvendig.
3. Fjern offentlige lenker, skjema, OAuth-redirects og aktive integrasjoner.
4. Fjern DNS-posten eller flytt den til et kontrollert sluttmål.
5. Vent til gammel DNS-cache er utløpt.
6. Bekreft at ingen offentlig trafikk når leverandørressursen gjennom subdomenet.
7. Fjern custom-domain-binding og slett ressursen.
8. Fjern verifikasjonsposter bare når leverandørens dokumentasjon sier det er trygt.
9. Oppdater inventar, sertifikater og overvåking.

GitHub dokumenterer for eksempel at verifisering av et egendefinert domene begrenser hvilke kontoer som kan publisere på domenet. GitHub advarer også mot wildcard-DNS og anbefaler at verifikasjonsposten beholdes. Følg den aktuelle plattformens mekanisme; ikke anta at én TXT-post virker likt hos alle.

Wildcard-DNS trenger særskilt kontroll

En post som *.bedrift.no kan sende ethvert ikke-eksisterende navn til samme plattform. Det gjør midlertidige og feilskrevne navn aktive uten at de står eksplisitt i sonen.

Før wildcard brukes, avklar:

• om plattformen krever verifisering for hvert custom domain
• hvor dypt wildcarden gjelder
• hvilke cookies og sikkerhetspolicyer som arves
• om ukjente vertsnavn avvises eller får standardinnhold
• hvordan navn inventarieres og avvikles
• om wildcardsertifikat er nødvendig

Bruk eksplisitte DNS-navn når wildcard ikke gir en klar driftsgevinst.

Forebygging som del av vanlig drift

Koble DNS til ressursens livsløp

Opprett DNS og skyressurs gjennom samme endringssak eller automatisering. Ressursen skal ikke kunne slettes uten at DNS-eier varsles. Plattformens delete lock eller tilsvarende kan være et nyttig stoppunkt.

Bruk plattformens domeneverifisering

Behold TXT-verifisering eller tenantbinding så lenge dokumentasjonen anbefaler det. Dette kan gjøre en hengende peker mindre farlig, men erstatter ikke opprydding.

Sett eier og utløpsdato

Kampanjer, testmiljøer og proof-of-concept-navn skal ha navngitt eier og dato for ny vurdering. Varsle før prosjekt, abonnement eller leverandørkonto avsluttes.

Overvåk endringer og feil

Varsle på:

• nye eller endrede CNAME-, A-, AAAA-, NS- og MX-poster
• mål som går fra gyldig svar til NXDOMAIN
• ukjente sertifikater i CT
• leverandørfeilsider på aktive navn
• navn uten matchende ressurs i skyinventaret

Gjennomgå tillit til hele domenet

Unngå vide regler for *.bedrift.no i cookies, CORS, CSP, OAuth og integrasjoner. Hvert subdomene bør få minst mulig tillit.

Sjekkliste for kvartalsvis kontroll

• Alle DNS-navn har en teknisk eier.
• Eksterne mål finnes i en konto virksomheten kontrollerer.
• Custom-domain-binding og verifikasjon er aktive.
• Ingen NS-delegering peker til en forlatt sone.
• Ingen utgått kampanje eller testressurs står i produksjons-DNS.
• Wildcard-poster har dokumentert behov og avgrensning.
• Sertifikater og CT-funn stemmer med inventaret.
• Cookies og tillatelseslister stoler ikke unødvendig på alle subdomener.
• Avvikling fjerner DNS før den eksterne ressursen frigjøres.
• Funn har eier, frist og ny kontroll.

Hva Vymo overvåker

Vymos standardtilbud er én enkel bedriftsnettside vi setter opp og hoster. Det publiserte tilbudet lover foreløpig ikke automatisk inventar eller takeover-overvåking for alle subdomener, skyressurser og DNS-soner virksomheten bruker hos andre leverandører.

Har dere mange subdomener, eksterne plattformer eller et konkret hengende DNS-funn, send Vymo navn, posttype og forventet tjeneste . Ikke send passord, API-nøkler, private sertifikatnøkler eller sensitive loggutdrag i skjemaet.

Subdomain takeover forebygges best som livsløpsstyring: DNS-navnet og ressursen opprettes, eies, overvåkes og avvikles sammen. Fjern pekeren før leverandørressursen kan frigjøres, og krev bevis før et automatisk treff kalles en sårbarhet.