Subdomain takeover: hoe een vergeten DNS-record de website van een vreemde wordt

Een subdomain takeover (overname van een subdomein) ontstaat wanneer een DNS-record van uw domein nog naar een externe dienst wijst die u niet meer gebruikt. Als die dienst iedereen toestaat de achtergelaten naam te claimen, kan een vreemde die registreren en eigen content tonen op promo.yourcompany.com. Bezoekers zien uw domein in de adresbalk en hebben geen enkele reden om aan de pagina te twijfelen.

De oorzaak is bijna altijd dezelfde: een zogenaamd "dangling DNS"-record, een verweesd record. Iemand heeft een campagnesite, een helpcenter of een testapplicatie op een cloudplatform gezet, er een subdomein naar laten wijzen en later de applicatie verwijderd, maar het DNS-record niet. Microsoft beschrijft precies dit verloop voor Azure, en hetzelfde patroon geldt voor veel hosting-, opslag- en SaaS-platformen.

Het goede nieuws: dit is in de kern een administratief probleem, en u kunt het zelf controleren met een paar DNS-opvragingen.

Hoe een verweesd record tot een overname leidt

Het probleem doorloopt doorgaans 3 stappen:

1. Aanmaak. Een team maakt yourcompany-promo.azurewebsites.net aan (of een bucket, een Pages-site, een CDN-endpoint) en voegt een CNAME toe zodat promo.yourcompany.com daarnaar wijst.
2. Opheffing. De campagne loopt af, de applicatie wordt verwijderd, maar niemand haalt de CNAME weg. Het subdomein wijst nu naar een naam die niet meer van u is.
3. Overname. Iemand merkt de verweesde naam op, maakt op hetzelfde platform een resource met dezelfde naam aan en bepaalt vanaf dat moment wat promo.yourcompany.com toont.

Niet elk platform maakt die laatste stap mogelijk. Het communityproject can-i-take-over-xyz houdt een lijst van diensten bij, geeft aan welke kwetsbaar zijn en noteert de foutmelding die elk ervan toont voor een niet-geclaimde naam, bijvoorbeeld "The specified bucket does not exist" bij Amazon S3.

Waarom het ernstiger is dan een bekladde webpagina

Een overgenomen subdomein is meer dan een gênante pagina. Volgens de richtlijnen van Microsoft gaat het onder meer om deze risico's:

• Diefstal van cookies. Veel webapplicaties zetten sessiecookies op *.yourcompany.com, waardoor elk subdomein ze kan lezen.
• Een geldig certificaat voor de aanvaller. Wie het subdomein beheert, kan er een TLS-certificaat voor aanvragen, zodat ook het hangslotje verschijnt.
• Overtuigende phishing. Een inlogpagina op uw echte domein valt veel moeilijker op dan een op een lookalike-domein.
• Onderschepte e-mail. Een verweesd MX-record kan iemand in staat stellen e-mail te ontvangen die naar dat subdomein wordt gestuurd.

De OWASP Web Security Testing Guide voegt daar de ernstigste variant aan toe: een NS-record dat een subdomein delegeert naar nameservers op een domein dat niet meer geregistreerd is. Wie dat domein registreert, beheert de volledige gedelegeerde zone.

Zo controleert u uw eigen DNS

Begin met een lijst van al uw subdomeinen. De zone-export van uw DNS-provider is daarvoor de beste bron. De certificaatgeschiedenis is een nuttige tweede bron, omdat vrijwel elk certificaat dat voor uw namen is uitgegeven, wordt vastgelegd in Certificate Transparency-logs.

Kijk voor elk subdomein waar het naartoe wijst:

dig +short CNAME promo.yourcompany.com
dig +short NS dev.yourcompany.com
dig +short MX shop.yourcompany.com

Controleer daarna of elk doel nog bestaat en nog van u is:

dig promo.yourcompany.com
curl -sI https://promo.yourcompany.com

Waarschuwingssignalen:

• het CNAME-doel geeft NXDOMAIN terug (de naam bestaat niet meer),
• de pagina toont een platformfout zoals "No such app", "Repository not found" of "There isn't a GitHub Pages site here",
• een NS-record wijst naar nameservers op een domein dat u niet kent of dat verlopen is,
• niemand in het bedrijf kan zeggen waarvoor het subdomein diende.

Test alleen namen op uw eigen domein. Probeer geen resource te claimen om het probleem te "bewijzen"; het record verwijderen is voldoende.

Zo lost u het op

1. Verwijder het verweesde record uit uw DNS-zone. Dat is de oplossing in zowel de richtlijnen van Microsoft als die van OWASP.
2. Is het subdomein nog nodig, maak de resource dan opnieuw aan onder uw eigen account voordat u er weer verkeer naartoe stuurt.
3. Ga na of er iets is gebeurd terwijl het record verweesd was: ongebruikelijke certificaten voor die naam, links in uw applicatie of e-mails die de naam nog gebruiken, OAuth-redirect-URL's waarin hij voorkomt.
4. Gebruik eigendomsverificatie waar het platform die aanbiedt. Azure App Service ondersteunt bijvoorbeeld een TXT-record asuid.<subdomain>, zodat geen ander abonnement het aangepaste domein kan valideren.
5. Herstel het proces, niet alleen het record. Zet "DNS-record verwijderen" op de checklist voor het uitfaseren van elke dienst en houd een eenvoudig overzicht bij van welk subdomein naar welk platform wijst en wie de eigenaar is.

Korte checklist

• Exporteer uw DNS-zone en maak een lijst van alle CNAME-, NS- en MX-records.
• Bevestig voor elk record dat het doel bestaat en van uw bedrijf is.
• Verwijder records van diensten die zijn stopgezet.
• Vergelijk uw zone met de namen in de Certificate Transparency-logs om subdomeinen te vinden die nergens gedocumenteerd zijn.
• Controleer opnieuw telkens wanneer een campagne, product of leverancier stopt.

Verweesde records staan vaak naast andere vergeten onderdelen, zoals oude staging- en testservers. Beide tegelijk opruimen levert meestal de snelste winst op.

De rol van Datahorses

Datahorses bewaakt uw bedrijf dagelijks van buitenaf: we stellen de lijst van uw subdomeinen samen, controleren waar elke CNAME naartoe wijst en signaleren records die naar diensten leiden die niet meer bestaan. We gaan uw systemen niet binnen en hebben geen toegang nodig, en bij elke bevinding krijgt uw ontwikkelaar de precieze herstelstappen. Bekijk de volledige lijst van wat wij bewaken of het voorbeelddashboard.