Subdomain takeover: Angrepet som rammer nedlagte tjenester

Hvordan subdomain takeover fungerer

Mekanismen er enkel. Bedriften din oppretter blog.firmanavn.no og konfigurerer en CNAME-record som peker til firmanavn.herokuapp.com. Etter seks måneder migrerer dere bloggen til WordPress og sletter Heroku-appen. Men DNS-recorden? Den ligger fortsatt der og peker inn i tomrommet.

Nå kan hvem som helst registrere firmanavn.herokuapp.com på nytt. Heroku gir dem kontrollen. De deployer phishing-innhold eller skadelig kode. Besøkende ser blog.firmanavn.no i adressefeltet og stoler på innholdet. Ditt SSL-sertifikat validerer tilkoblingen.

Lignende scenarioer gjelder AWS S3-buckets, Azure-instanser, GitHub Pages, Shopify-butikker, Zendesk-sider og dusinvis av andre plattformer. Hver gang du sletter en ekstern ressurs uten å oppdatere DNS, etterlater du døren åpen.

Reelle case-studier

I 2020 overtok forskere subdomener tilhørende Microsoft, Snapchat og eBay gjennom forlatte Azure-instanser. Microsoft betalte ut 40 000 dollar i bug bounty for funnet. I 2021 demonstrerte sikkerhetsselskapet Detectify at 1 av 20 Fortune 500-selskaper hadde minst ett sårbart subdomene.

Et norsk case fra 2023 involverte et offentlig etats testmiljø. Subdomenet test.etat.no pekte til en nedlagt AWS Elastic Beanstalk-instans. En etisk hacker registrerte miljøet på nytt og varslet. Hadde en angriper kommet først, kunne de distribuert skadevare som så ut til å komme fra en statlig kilde.

Konsekvensene strekker seg utover phishing. Angripere kan utnytte sårbare subdomener til å omgå Content Security Policy (CSP), sette cookies på hoved-domenet, eller kompromittere Single Sign-On-flyter som stoler på subdomene-autentisitet.

Slik oppdager du sårbarheten

Start med å kartlegge alle DNS-records. Kjør dig firmanavn.no ANY eller bruk et verktøy som returnerer CNAME-pekere. For hvert subdomene som peker eksternt, verifiser at ressursen faktisk eksisterer.

Vanlige røde flagg:

• CNAME peker til *.herokuapp.com, men Heroku svarer "No such app"
• CNAME mot S3-bucket returnerer NoSuchBucket-feil (HTTP 404)
• Azure-instans gir 404 Web App Not Found
• GitHub Pages returnerer "There isn't a GitHub Pages site here"
• Shopify-butikk viser "Sorry, this shop is currently unavailable"

Automatiser dette. Skriv et script som kjører DNS-oppslag ukentlig og verifiserer at hver CNAME-destinasjon responderer med gyldig innhold. Alternativt, sett opp kontinuerlig overvåkning som varsler når et subdomene plutselig returnerer en feilmelding.

Konkrete steg for å fikse

Når du identifiserer et sårbart subdomene, har du to alternativer. Det sikreste er å slette DNS-recorden helt. Hvis old-blog.firmanavn.no ikke lenger er i bruk, fjern A-recorden eller CNAME-pekeren. Ingen record betyr ingen risiko.

Hvis subdomenet må eksistere (kanskje det er lenket fra ekstern dokumentasjon), lag en ny ressurs internt. Pek CNAME-recorden til en server du kontrollerer, og sett opp en statisk side som forklarer at tjenesten er nedlagt. Nå kan ingen andre registrere pekeren.

For å forhindre fremtidige problemer, etabler en rutine: hver gang et eksternt prosjekt legges ned, oppdater DNS samme dag. Dokumenter alle eksterne CNAME-pekere i et sentralt register med eier og formål. Sett opp CAA-records som begrenser hvilke Certificate Authorities som kan utstede sertifikater for domenene dine, dette gjør det vanskeligere for en angriper å få HTTPS på et overtatt subdomene.

Teknisk forsvarsmekanisme

Implementer DNSSEC for å beskytte mot DNS-spoofing, selv om det ikke direkte stopper subdomain takeover. Aktiver CAA-records med streng policy. For eksempel:

firmanavn.no. CAA 0 issue "letsencrypt.org"
firmanavn.no. CAA 0 issuewild ";"

Dette tillater Let's Encrypt å utstede sertifikater for hoved-domenet, men blokkerer wildcard-sertifikater helt. En angriper som overtar et subdomene må da gå via din godkjente CA, noe som krever domain validation du kan oppdage.

Hvorfor dette fortsatt skjer

Problemet er organisatorisk, ikke teknisk. Utviklingsteamet spinner opp en Heroku-app for en proof-of-concept. Markedsavdelingen bestiller et eksternt Shopify-domene for en kampanje. IT-avdelingen vet ikke om disse CNAME-recordene eksisterer før det er for sent.

Mangel på DNS-inventar er kjerneproblemet. I vår overvåkning ser vi at 4 av 14 bedrifter har deaktivert DNSSEC, mens 7 mangler eller har svak DMARC-konfigurasjon, tegn på at DNS-hygiene ikke prioriteres. Subdomain takeover er et symptom på den samme underliggende svakheten.

Veien videre

Gjør en full DNS-audit i dag. List alle subdomener, sjekk hvor de peker, og verifiser at destinasjonen eksisterer. Slett det som ikke trengs. Dokumenter resten.

Deretter, automatiser. Sett opp daglig overvåkning som varsler når et subdomene begynner å returnere feilmeldinger som indikerer en glemt ressurs. Implementer CAA-records og DNSSEC. Og viktigst: lag en prosess som sikrer at DNS oppdateres hver gang en ekstern tjeneste avvikles.

Subdomain takeover er ikke et hipt nytt angrep. Det er en grunnleggende sikkerhetssvikt som har eksistert i over ti år. Men den er fortsatt effektiv fordi DNS-hygiene er kjedelig, usynlig arbeid som faller mellom to stoler. Inntil noen overtar login.firmanavn.no, og plutselig er det ikke kjedelig lenger.

Vil du sjekke dine egne domener? Sentinel overvåker daglig for glemte CNAME-pekere, manglende CAA-records, og eksponerte subdomener som en del av PLUSS-abonnementet. Start med en engangs-sjekk av sertifikater og DNS-konfigurasjon på certscan, eller se hele domene-sikkerhetsprofilen via kontinuerlig overvåkning på Sentinel.