Onverwachte wijziging van nameserver of registrar: vroege signalen van domeinkaping

Domeinkaping (domain hijacking) betekent dat iemand anders dan u bepaalt waar uw domein naartoe wijst. De meest directe manieren zijn de nameservers wijzigen, het domein naar een andere registrar verhuizen of DNS-records aanpassen in uw account bij de DNS-provider. Elk daarvan is een normale beheerhandeling, en juist daarom is een onverwachte wijziging het vroegste en duidelijkste waarschuwingssignaal.

Wie uw DNS beheert, kan de bezoekers van uw website en uw inkomende e-mail naar eigen servers sturen. Omdat hij het domein beheert, kan hij er ook geldige TLS-certificaten voor krijgen, zodat bezoekers geen enkele waarschuwing in de browser zien.

Het goede nieuws is dat zulke wijzigingen van buitenaf zichtbaar zijn, en dat registrars en registries vergrendelingen aanbieden die ze veel moeilijker maken.

Hoe DNS-kaping in de praktijk gebeurt

In januari 2019 vaardigde CISA Emergency Directive 19-01 uit na een campagne waarin aanvallers inloggegevens hadden bemachtigd van accounts waarmee DNS-records konden worden gewijzigd. Ze pasten A-, MX- en NS-records aan om web- en mailverkeer via hun eigen infrastructuur te leiden, en verkregen geldige certificaten voor de getroffen domeinen. De richtlijn (inmiddels ingetrokken) verplichtte overheidsinstanties om DNS-records te controleren, wachtwoorden van DNS-accounts te wijzigen, multifactorauthenticatie in te schakelen en Certificate Transparency-logs te volgen. Die 4 stappen blijven voor elke organisatie een goede basis.

De gebruikelijke toegangswegen zijn:

• Een gecompromitteerde login bij de registrar of DNS-provider, vaak via een hergebruikt of gephisht wachtwoord.
• Een gecompromitteerd e-mailaccount dat de wachtwoordherstelberichten van de registrar ontvangt.
• Social engineering van de supportmedewerkers van de registrar.
• Een verlopen domein dat iemand anders opnieuw registreert.
• Een vergeten DNS-record dat nog naar een dienst wijst die u niet meer gebruikt, een verwant risico dat we beschrijven bij subdomain takeover.

Hoe een onverwachte wijziging eruitziet

Leg vast wat normaal is voor uw domein en vergelijk daarna:

• Nameservers (NS): een overstap van uw gebruikelijke DNS-provider naar onbekende servers.
• Registrar: het domein staat nu bij een registrar waarmee u nooit hebt gewerkt.
• A-, AAAA- en CNAME-records: uw website wijst plots naar een IP-adres in een netwerk dat u niet gebruikt.
• MX-records: e-mail loopt via een server die u niet hebt ingericht.
• EPP-statuscodes: beschermende vergrendelingen zoals clientTransferProhibited zijn zonder reden verwijderd.
• Nieuwe certificaten: een certificaat voor uw domein, uitgegeven door een CA die u niet gebruikt.

Zo controleert u uw domein zelf

Lees de huidige waarden rechtstreeks uit:

dig NS example.com +short
dig A example.com +short
dig MX example.com +short
whois example.com | grep -i -E "registrar:|name server|status"

Bewaar de uitvoer. Voer dezelfde opdrachten regelmatig uit en vergelijk. Een verschil dat u niet kunt verklaren, is reden om meteen navraag te doen bij wie uw DNS beheert.

Zoek voor certificaten in de Certificate Transparency-logs op crt.sh naar uw domein en kijk wie de uitgevers zijn. Meer daarover in Certificate Transparency-logs uitgelegd.

Vergrendelingen: registrar lock en registry lock

Het overzicht van EPP-statuscodes van ICANN beschrijft de statussen die een domein beschermen:

• clientTransferProhibited: ingesteld door uw registrar. De registry weigert verzoeken om het domein naar een andere registrar te verhuizen. Dit is de gangbare "registrar lock" en hoort aan te staan voor elk domein dat u niet actief verhuist.
• clientUpdateProhibited en clientDeleteProhibited: de registry weigert wijzigingen of verwijdering tot uw registrar de status opheft.
• Registry lock: sommige registry-beheerders bieden een dienst die serverUpdateProhibited, serverTransferProhibited en serverDeleteProhibited instelt. Die worden op het niveau van de registry gezet en niet in uw account bij de registrar, en ICANN merkt op dat het opheffen van een serverstatus doorgaans langer duurt, wat precies de bedoeling is. Vraag uw registrar of dit beschikbaar is voor uw topleveldomein.

Een registrar lock alleen helpt niet als de aanvaller inlogt op uw account bij de registrar, want dan kan hij de lock zelf verwijderen. Een registry lock voegt een stap toe buiten dat account, zodat een gestolen wachtwoord van de registrar alleen niet volstaat.

De accounts die uw DNS beheren beter beveiligen

• Multifactorauthenticatie op de accounts bij registrar en DNS-provider, bij voorkeur met een beveiligingssleutel of passkey in plaats van sms.
• Een apart contactadres voor de registrar, op een mailbox die even sterk beveiligd is als het registraraccount zelf.
• Weinig mensen met toegang, en toegang intrekken wanneer iemand vertrekt.
• Een CAA-record met de certificaatautoriteiten die u gebruikt, gedefinieerd in RFC 8659. Bijvoorbeeld:

example.com.  CAA 0 issue "letsencrypt.org"

CAA houdt een kaper die uw DNS in handen heeft niet tegen om het record aan te passen, maar het maakt ongeplande uitgifte door andere CA's moeilijker, en een wijziging van het CAA-record wordt zelf een signaal.

Als u een wijziging ziet die u niet zelf hebt gedaan

1. Neem contact op met uw registrar en DNS-provider via een bekend kanaal, niet via een link uit een e-mail.
2. Herstel de juiste NS-, A- en MX-records en schakel de vergrendelingen opnieuw in.
3. Wijzig de wachtwoorden en stel de multifactorauthenticatie opnieuw in op die accounts en op het e-mailaccount dat hun meldingen ontvangt.
4. Zoek in de Certificate Transparency-logs naar certificaten die in die periode zijn uitgegeven en vraag de uitgevende CA om elk certificaat in te trekken dat u niet hebt aangevraagd.
5. Beschouw wachtwoorden en sessies die in die periode op uw site en in uw e-mail zijn gebruikt als mogelijk uitgelekt.

Checklist

• Basislijn van NS, A, MX, registrar en statuscodes opgeslagen.
• Registrar lock ingeschakeld, registry lock overwogen.
• Multifactorauthenticatie op registrar, DNS en de gekoppelde mailbox.
• CAA-record gepubliceerd.
• Regelmatige vergelijking met de basislijn.

De rol van Datahorses

Datahorses bewaakt uw bedrijf van buitenaf en controleert uw nameservers, registrar, DNS-records en nieuw uitgegeven certificaten op wijzigingen. We gaan uw systemen niet binnen en hebben geen toegang nodig. Een onverwachte wijziging wordt door een specialist beoordeeld en naar u gestuurd met wat er veranderde, wanneer, en wat u eerst moet doen. Bekijk hoe wij bewaken en wat er gebeurt als we iets vinden.