Neem het volgende scenario: uw organisatie met de domeinnaam “organisatie.nl” heeft net een nieuwe applicatie uitgerold op het subdomein “app.organisatie.nl”, toegankelijk voor publiek gebruik.
De applicatie maakt voor het hosten van de applicatie gebruik van verschillende clouddiensten, waaronder de bekende cloudopslagdienst Amazon AWS S3. Voordat de applicatie werd uitgerold voor publiek gebruik, is voor testen en het releaseproces een acceptatie-omgeving gehost op het subdomein “acceptatie-app.organisatie.nl”. Dit subdomein wordt echter niet meer gebruikt nu de productie-omgeving online is. De ontwikkelaars hebben de AWS S3 bucket voor de acceptatie-omgeving verwijderd en een nieuwe bucket aangemaakt voor de productie-omgeving op “app.organisatie.nl”. Hierbij hebben de ontwikkelaars echter een kritische fout gemaakt: na het verwijderen van de S3 bucket vergeten ze het subdomein “acceptatie-app.organisatie.nl”, met een DNS-record dat nog wijst naar de oude S3 bucket, te verwijderen uit de DNS-zone! Het domein is nu kwetsbaar voor subdomein overname.

Het bovenstaande is een realistisch scenario dat de pentesters bij nSEC/Resilience regelmatig tegenkomen. Vergelijkbare scenario’s komen ook voor met andere diensten, resources en platformen zoals Microsoft Azure, Bitbucket of Digital Ocean.

Subdomein overname in de praktijk

Subdomein overname (ook wel bekend als subdomain hijacking) is een groeiend probleem voor bedrijven als het gaat om hun externe aanvalsoppervlak. De overname van een subdomein is relatief gemakkelijk voor hackers, maar heeft mogelijk een grote impact op de organisatie.

Een subdomein is een deel van een hoofddomein, zoals “app.organisatie.nl” een subdomein van “organisatie.nl” is. Wanneer een hacker een subdomein weet over te nemen kan dit subdomein vervolgens voor verschillende doeleinden worden gebruikt. Denk aan verlies van controle over de inhoud van het subdomein: een aanvaller kan op het domein een phishing-scam website opzetten, waar een legitiem (sub)domein van uw organisatie naar verwijst. Hiermee kan malware worden verspreid of kunnen man-in-the-middle aanvallen worden uitgevoerd voor het verzamelen van data over bezoekers en het misbruiken van kwetsbaarheden in andere domeinen van de organisatie, zoals XSS, CSRF en CORS-bypass. Ook kan een aanvaller inkomend verkeer op het domein opvangen en analyseren; als er nog een oude verwijzing is naar het overgenomen domein kan het zijn dat authenticatiecookies of headers nog per abuis naar het oude domein worden gestuurd en daardoor in handen vallen van een aanvaller.

Er zijn een aantal manieren waarop hackers een subdomein overname kunnen uitvoeren. Een veelvoorkomende methode is het vissen naar bungelende DNS-records. Het DNS is de koppeling tussen de browser en de website die iemand bezoekt. Het DNS werkt als een vertaalsysteem dat een domeinnaam, zoals nsec-resilience.com, omzet naar een IP-adres. De computer benadert dit IP-adres en toont hierbij de juiste website. Een DNS-configuratie bestaat uit een aantal verschillende DNS-records. Deze records kunnen gezien worden als uitgebreide instructies voor het ophalen van de juiste gegevens wanneer een gebruiker een URL bezoekt, waaronder A records, AAAA records, CNAME records, NS records, MX records & TXT records. De verschillende records hebben ieder hun eigen taak binnen de DNS-zone.

Vissen naar bungelende DNS-records

In het beschreven scenario spelen met name de CNAME-records een belangrijke rol. CNAME-records worden veelal gebruikt om een subdomein te koppelen aan het domein waarin de content van het subdomein wordt gehost.
Een bungelend DNS-record is een record dat wijst naar een service/resource welke niet langer in gebruik is door de organisatie. Normaal gesproken zou dit DNS-record verwijderd moeten worden van de DNS-zone, maar in de praktijk gebeurt dit niet altijd.
Dit is het probleem dat terug te zien is in het eerder beschreven scenario. Hoewel de organisatie eerst gebruik heeft gemaakt van een S3 bucket voor hun acceptatie-omgeving, hebben ze deze bucket verwijderd zonder de verwijzing in het DNS te verwijderen.

Bij het bezoeken van het domein van de acceptatie-omgeving verschijnt nu de error “NoSuchBucket”.

Het CNAME-record van het subdomein van de acceptatie-omgeving verwijst echter nog steeds naar deze bucket, omdat het CNAME record niet verwijderd is uit de DNS-zone. Dit kan een hacker vrij gemakkelijk achterhalen door een lijst van alle bekende subdomeinen op te stellen en vervolgens de DNS-records van deze subdomeinen te benaderen. Google heeft bijvoorbeeld een handige tool voor het checken van DNS-records voor individuele domeinen: https://toolbox.googleapps.com/apps/dig/#CNAME/

Natuurlijk kunnen hackers dit proces ook op slimme manieren automatiseren met tools en scripts.

Bij het kwetsbare domein met de “NoSuchBucket” error is in het CNAME-record een verwijzing te vinden die er bijvoorbeeld als volgt uitziet:

Een hacker kan nu op zijn/haar eigen Amazon AWS portal inloggen en met behulp van het CNAME-record de exacte S3 bucket registreren die gebruikt werd in de acceptatie-omgeving; het domein is kwetsbaar voor subdomein overname.

Aangezien het subdomein nog naar de S3 bucket verwijst zal de hacker volledige controle hebben over het subdomein wanneer de S3 bucket succesvol is geregistreerd.

Voorkomen van subdomain overname

Achterliggend probleem is dat veel organisaties hun DNS configuraties niet regelmatig checken en ook geen gestandaardiseerd proces hebben voor het toevoegen, wijzigen of verwijderen van records uit hun DNS-zonebestand.

Om de risico’s van subdomein overnames te mitigeren wordt dan ook aanbevolen om regelmatig controles uit te voeren en te monitoren welke subdomeinen in gebruik zijn, welke subdomeinen niet meer in gebruik zijn, welke diensten/resources op deze subdomeinen draaien en of alles matcht met de aanwezige DNS-records. Daarnaast zal het hebben van een standaard proces voor het toevoegen, wijzigen of verwijderen van records uit het DNS-zonebestand bijdragen bij de digitale hygiëne van de organisatie. Een goede procedure helpt in dit geval bij het beperken van het externe aanvalsoppervlak van uw organisatie.

Mocht u meer willen lezen over subdomein overnames, dan is op GitHub een handige repository te vinden van diensten waarvan het bekend is dat deze kwetsbaar kunnen zijn voor subdomein overname. Zie ook https://github.com/EdOverflow/can-i-take-over-xyz 

Geschreven door Jesse van Eekelen, gepost op 27 januari 2023

Benieuwd of uw organisatie kwetsbaar is voor subdomein overname en wat nSEC/Resilience hier in kan betekenen? We vertellen u er graag meer over. Neem contact met ons op voor meer informatie of bekijk onze pakketten/prijzen pagina!