Aanvallers verkrijgen geldige HTTPS-certificaten voor Google via DNS-kaping

Aanvallers zijn erin geslaagd om geldige HTTPS-certificaten te verkrijgen voor domeinen van Google en andere grote organisaties, zonder daarvoor in te breken op de systemen van die bedrijven. De aanvallers maakten misbruik van een kwetsbaarheid in de DNS-infrastructuur achter drie landcode-topleveldomeinen: Ghana (.gh), Sierra Leone (.sl) en Amerikaans-Samoa (.as).

Door de DNS-infrastructuur van deze domeinen te compromitteren, konden de aanvallers wijzigingen aanbrengen in DNS-records. Daarmee konden zij zich tegenover certificaatautoriteiten voordoen als de rechtmatige beheerders van bepaalde domeinen. Vervolgens konden voor die domeinen HTTPS-certificaten worden aangevraagd en uitgegeven.

Dat maakt de aanval bijzonder. Een HTTPS-certificaat dat door een browser als geldig wordt beschouwd, betekent normaal gesproken dat de browser erop kan vertrouwen dat de verbinding met het juiste domein wordt opgezet. In dit geval beschikten de aanvallers echter over certificaten die formeel geldig waren, terwijl zij niet de rechtmatige eigenaren van de betreffende websites waren.

Google heeft inmiddels maatregelen genomen om de bekende misbruikte certificaten in Chrome te blokkeren. Daarnaast zijn de betrokken certificaten door certificaatautoriteiten ingetrokken en worden organisaties gewaarschuwd wanneer hun domeinen mogelijk zijn getroffen.

Geen inbraak bij Google nodig

Bij de aanval hoefden de aanvallers geen toegang te krijgen tot de interne systemen van Google of andere getroffen organisaties.

De kern van het probleem zat in de infrastructuur waarmee het internet bepaalt welke server bij een domeinnaam hoort. Het Domain Name System, beter bekend als DNS, vertaalt domeinnamen zoals google.com naar IP-adressen. Wanneer een aanvaller controle krijgt over de relevante DNS-infrastructuur, kan hij onder bepaalde omstandigheden bepalen welk IP-adres aan een domeinnaam wordt gekoppeld.

Dat kan grote gevolgen hebben.

Een aanvaller die bijvoorbeeld tijdelijk kan bepalen waar een bepaalde domeinnaam naartoe verwijst, kan een eigen server als bestemming aanwijzen. Wanneer vervolgens een certificaatautoriteit controleert of de aanvrager daadwerkelijk controle heeft over het domein, kan die controle door de gemanipuleerde DNS-informatie succesvol worden doorlopen.

De certificaatautoriteit hoeft daarmee niet noodzakelijk te zijn gehackt of misleid door een fout in haar eigen systemen. Vanuit haar perspectief kan de vereiste domeinvalidatie immers correct zijn uitgevoerd. Het probleem is dat de DNS-infrastructuur waarop die controle vertrouwt op dat moment door een aanvaller werd beheerd.

DNS als zwakke schakel

DNS vormt een fundamenteel onderdeel van het internet. Wanneer een gebruiker een website bezoekt, wordt de domeinnaam via DNS gekoppeld aan de infrastructuur waarop de website draait.

Organisaties vertrouwen daarbij op verschillende DNS-records en DNS-servers. Die infrastructuur is doorgaans verdeeld over meerdere systemen en dienstverleners. Wanneer aanvallers controle weten te krijgen over een onderdeel dat als autoritatief voor een domein of een topleveldomein geldt, kunnen zij DNS-antwoorden manipuleren.

In dit geval kregen aanvallers de mogelijkheid om autoritatieve DNS-records binnen de infrastructuur van .gh, .sl en .as te wijzigen. Daardoor konden zij domeinen laten verwijzen naar systemen die zij zelf controleerden.

Het gaat daarmee niet om een klassieke aanval waarbij een wachtwoord van een Google-medewerker wordt gestolen of waarbij rechtstreeks wordt ingebroken op een webserver. De aanvallers misbruiken een vertrouwensketen rondom domeinnamen en certificaten.

Hoe een geldig certificaat kon worden verkregen

Voor een HTTPS-verbinding wordt gebruikgemaakt van een TLS-certificaat. Zo'n certificaat bevat onder meer informatie over het domein waarvoor het is uitgegeven en wordt digitaal ondertekend door een certificaatautoriteit die door browsers wordt vertrouwd.

Voordat een certificaatautoriteit een certificaat uitgeeft, moet zij controleren of de aanvrager daadwerkelijk controle heeft over het betreffende domein.

Dat kan op verschillende manieren. Een veelgebruikte methode is DNS-validatie. Daarbij moet de aanvrager bijvoorbeeld een specifieke DNS-record plaatsen of wijzigen. Als de certificaatautoriteit die verwachte record kan terugvinden, kan zij concluderen dat de aanvrager controle over het domein heeft.

Precies dat vertrouwensmechanisme werd in deze aanval misbruikt.

Doordat de aanvallers de relevante DNS-infrastructuur konden manipuleren, konden zij de antwoorden beïnvloeden waarop de certificaatautoriteit haar controle baseerde. Daardoor konden zij domeinvalidaties succesvol laten verlopen zonder daadwerkelijk eigenaar te zijn van de betrokken organisaties of toegang te hebben tot hun interne systemen.

Het resultaat was een HTTPS-certificaat dat cryptografisch correct was ondertekend door een vertrouwde certificaatautoriteit.

Voor een browser zag dat certificaat er dus legitiem uit.

Een geldig certificaat betekent niet automatisch een legitieme website

Dat onderscheid is belangrijk.

Wanneer een browser een HTTPS-certificaat accepteert, controleert hij onder meer of het certificaat geldig is, of het voor de bezochte domeinnaam is uitgegeven en of de certificaatautoriteit die het certificaat heeft ondertekend wordt vertrouwd.

Als al die controles succesvol zijn, verschijnt normaal gesproken geen certificaatwaarschuwing.

Een aanvaller die door DNS-manipulatie een geldig certificaat voor een domein heeft verkregen, kan daardoor een server exploiteren die zich technisch gezien voordoet als de betreffende website.

Het certificaat is dan niet vervalst in de klassieke betekenis van het woord. Het is een echt, door een vertrouwde certificaatautoriteit uitgegeven certificaat. Alleen de persoon of organisatie die het certificaat heeft verkregen, is niet de rechtmatige beheerder van het domein.

Dat maakt dit type aanval potentieel gevaarlijk.

Wat een aanvaller vervolgens kan doen

Wanneer een aanvaller zowel de DNS-verwijzing als een geldig certificaat voor een domein kan controleren, kan hij verkeer naar zijn eigen infrastructuur leiden zonder dat een browser noodzakelijkerwijs een HTTPS-waarschuwing laat zien.

Op die server kan vervolgens een nagemaakte website worden aangeboden die er voor gebruikers vrijwel identiek uitziet aan de oorspronkelijke website.

Dat kan bijvoorbeeld worden gebruikt voor phishing. Een gebruiker kan denken dat hij verbinding maakt met een vertrouwde website, terwijl de gegevens in werkelijkheid naar een server van de aanvaller worden gestuurd.

Afhankelijk van de omstandigheden kan een aanvaller proberen inloggegevens, sessietokens of andere gevoelige informatie te verzamelen. Ook kan een dergelijke infrastructuur worden gebruikt om gebruikers naar kwaadaardige inhoud te leiden.

Daarbij moet wel worden benadrukt dat het verkrijgen van een certificaat op zichzelf niet betekent dat aanvallers automatisch al het verkeer van een website konden onderscheppen. Daarvoor moeten zij ook in staat zijn het verkeer daadwerkelijk naar hun eigen infrastructuur te leiden en moet de netwerkomgeving daarvoor geschikt zijn.

Er zijn vooralsnog geen aanwijzingen dat Google-systemen zelf zijn binnengedrongen of dat Google-gebruikers als gevolg van dit incident daadwerkelijk zijn afgeluisterd of dat gegevens zijn buitgemaakt.

Ook andere organisaties getroffen

De aanvallen bleven niet beperkt tot Google.

Tijdens onderzoek naar de incidenten werden in openbare Certificate Transparency-logs meerdere certificaten aangetroffen die vermoedelijk zonder toestemming voor verschillende organisaties waren uitgegeven. Daaronder bevonden zich volgens Google meerdere internationaal bekende merken en veelgebruikte online diensten.

Google heeft niet alle getroffen organisaties publiekelijk bij naam genoemd.

Certificate Transparency speelt hierbij een belangrijke rol. Dit zijn openbare logboeken waarin certificaatautoriteiten certificaatuitgiftes registreren. Daardoor kunnen domeineigenaren en beveiligingsonderzoekers achteraf controleren welke certificaten voor hun domeinen zijn uitgegeven.

Zonder deze openbare registratie zou het veel moeilijker zijn om ongeautoriseerde certificaten op te sporen.

Google blokkeert certificaten in Chrome

Google heeft voor de eigen getroffen domeinen direct maatregelen genomen in Chrome.

Het bedrijf gebruikte daarvoor onder meer CRLSets. Dit is een mechanisme waarmee Chrome specifieke certificaten kan blokkeren wanneer Google vaststelt dat deze niet langer vertrouwd mogen worden.

Dat is belangrijk omdat het intrekken van een certificaat niet betekent dat iedere browser het certificaat onmiddellijk op dezelfde manier zal weigeren. Browsers verschillen in de manier waarop zij intrekkingsinformatie verwerken en hoe snel wijzigingen beschikbaar komen.

Door de betreffende certificaten rechtstreeks in Chrome te blokkeren, kan Google sneller voorkomen dat Chrome-gebruikers een verbinding met een server op basis van een bekend gecompromitteerd certificaat vertrouwen.

Daarnaast is samengewerkt met de betrokken certificaatautoriteiten om de certificaten formeel in te trekken.

Ook voor andere organisaties die mogelijk zijn getroffen, zijn verdachte certificaten geïdentificeerd en waar mogelijk geblokkeerd.

Gebruikers hoeven zelf niets te doen

Google geeft aan dat Chrome-gebruikers naar aanleiding van deze specifieke certificaten geen handmatige actie hoeven te ondernemen.

Dat betekent echter niet dat iedere gebruiker van iedere browser automatisch dezelfde bescherming heeft. Andere browsers beschikken over hun eigen mechanismen voor certificaatintrekking en blokkering.

De belangrijkste verantwoordelijkheid ligt daarom bij de certificaatautoriteiten, browserleveranciers en de organisaties die hun domeinen beheren.

Voor gebruikers blijft de algemene beveiligingsregel gelden dat browsers en besturingssystemen up-to-date moeten worden gehouden. Moderne browsers beschikken over meerdere beveiligingslagen die dergelijke incidenten kunnen beperken.

Waarom certificaatautoriteiten niet per se een fout hebben gemaakt

Op het eerste gezicht lijkt het vreemd dat een certificaatautoriteit een certificaat voor Google kan uitgeven aan iemand die Google niet vertegenwoordigt.

Toch hoeft dat niet te betekenen dat de certificaatautoriteit haar controleprocedure heeft overtreden.

Certificaatautoriteiten kunnen namelijk niet rechtstreeks vaststellen wie juridisch eigenaar is van iedere website. Zij gebruiken gestandaardiseerde methoden om te controleren of een aanvrager op dat moment controle heeft over het domein.

Bij DNS-validatie betekent dat in essentie dat een specifieke controle via DNS succesvol moet kunnen worden uitgevoerd.

Als de DNS-infrastructuur zelf is gecompromitteerd, kan een aanvaller die controle aantonen zonder de daadwerkelijke eigenaar te zijn.

Daarmee ontstaat een probleem in de vertrouwensketen:

domeineigenaar → DNS-infrastructuur → certificaatautoriteit → browser

Wanneer een aanvaller de DNS-laag weet te manipuleren, kan hij het bewijs leveren dat de certificaatautoriteit nodig heeft om een certificaat uit te geven.

De certificaatautoriteit kan vervolgens volgens de voorgeschreven procedure handelen, terwijl het uiteindelijke resultaat toch onrechtmatig is.

CAA-records kunnen helpen, maar zijn geen volledige oplossing

Google adviseert organisaties om Certification Authority Authorization, oftewel CAA, in te zetten.

Met CAA-records kan een domeineigenaar aangeven welke certificaatautoriteiten certificaten voor het domein mogen uitgeven.

Dat beperkt het aantal partijen dat een certificaat kan uitgeven. Een aanvaller die bijvoorbeeld een DNS-kaping uitvoert, kan daardoor minder eenvoudig bij iedere willekeurige certificaatautoriteit een certificaat aanvragen.

CAA is echter geen absolute bescherming tegen DNS-kaping.

Als een aanvaller volledige controle over de relevante DNS-infrastructuur heeft, kan hij in sommige situaties ook de CAA-records aanpassen. De aanvaller kan dan proberen de DNS-configuratie zo te wijzigen dat een certificaatautoriteit alsnog toestemming lijkt te hebben.

CAA moet daarom worden gezien als een extra beveiligingslaag en niet als een oplossing die een DNS-compromittering volledig voorkomt.

Ook bestaande domeinvalidaties vormen een risico

Een ander probleem is het hergebruik van eerder verkregen domeinvalidaties.

Wanneer een certificaatautoriteit eerder heeft vastgesteld dat iemand controle over een domein heeft, kan die informatie onder bepaalde omstandigheden gedurende enige tijd opnieuw worden gebruikt.

Dat is praktisch voor normale certificaatuitgifte, maar kan tijdens een DNS-kaping tegen de domeineigenaar werken.

Een aanvaller die tijdelijk controle over de DNS-infrastructuur verkrijgt, kan proberen binnen die periode zoveel mogelijk certificaten te laten uitgeven. Zelfs nadat de DNS-configuratie is hersteld, kunnen die certificaten nog enige tijd bruikbaar zijn als ze niet tijdig worden ingetrokken of door browsers worden geblokkeerd.

Daarom pleit Google onder meer voor een verdere beperking van de geldigheidsduur van HTTPS-certificaten en voor strengere beperkingen op het opnieuw gebruiken van domeinvalidaties.

Hoe korter de periode waarin een certificaat of validatie bruikbaar blijft, hoe kleiner het tijdvenster waarin een aanvaller na een succesvolle aanval misbruik kan blijven maken van de verkregen toegang.

Certificate Transparency is een belangrijke controlemogelijkheid

Google adviseert organisaties daarnaast om hun volledige domeinportfolio voortdurend te controleren via Certificate Transparency.

Dat is vooral belangrijk voor grote organisaties die honderden of duizenden domeinen en subdomeinen beheren. Het kan voor een beveiligingsteam moeilijk zijn om handmatig bij te houden welke certificaten overal worden uitgegeven.

Door de openbare certificaatlogs automatisch te monitoren, kan een organisatie relatief snel ontdekken dat er een certificaat is uitgegeven dat zij zelf nooit heeft aangevraagd.

Zo'n melding betekent niet automatisch dat er een aanval heeft plaatsgevonden. Er kunnen legitieme verklaringen zijn, bijvoorbeeld wanneer een externe dienstverlener of een andere afdeling binnen de organisatie het certificaat heeft aangevraagd.

Een onverwacht certificaat moet echter altijd worden onderzocht.

DNS-kaping vraagt om bredere beveiliging

Het incident laat vooral zien dat HTTPS niet op zichzelf staat.

TLS en HTTPS bieden sterke beveiliging wanneer de onderliggende vertrouwensketen intact is. Maar die keten bestaat uit meerdere onderdelen: domeinregistratie, DNS, certificaatautoriteiten, certificaatlogs en browsers.

Een aanvaller hoeft niet noodzakelijk de website zelf te hacken wanneer hij een zwakke plek in een van deze andere onderdelen kan misbruiken.

Dat maakt DNS-beveiliging een essentieel onderdeel van de totale beveiliging van een organisatie.

Organisaties zouden daarom niet alleen hun webservers en applicaties moeten beveiligen, maar ook zorgvuldig moeten controleren wie toegang heeft tot hun DNS-beheer, registraraccounts en accounts bij DNS-dienstverleners.

Sterke authenticatie, beperkte toegangsrechten, monitoring van DNS-wijzigingen en een duidelijke registratie van alle gebruikte domeinen en DNS-providers kunnen helpen om dergelijke aanvallen sneller te ontdekken en de impact ervan te beperken.

Het bredere probleem: vertrouwen op het internet

Het incident maakt een fundamenteel probleem zichtbaar in de beveiligingsarchitectuur van het internet.

HTTPS is ontworpen om gebruikers zekerheid te geven over de identiteit van een website en om communicatie tegen afluisteren en manipulatie te beschermen. Die beveiliging is echter gebaseerd op een keten van partijen die elkaar moeten kunnen vertrouwen.

Wanneer één schakel in die keten wordt gecompromitteerd, kan een aanvaller soms een certificaat verkrijgen dat voor browsers volledig legitiem lijkt.

Dat betekent niet dat HTTPS onveilig is. Integendeel: TLS blijft een van de belangrijkste beveiligingsmechanismen van het moderne internet. Het incident laat vooral zien dat HTTPS-certificaten slechts zo betrouwbaar zijn als het proces waarmee wordt vastgesteld wie het recht heeft om ze te verkrijgen.

Google wil de aanvalsmogelijkheden verder verkleinen

Google ziet de gebeurtenissen daarom als aanleiding om verschillende onderdelen van het certificaatecosysteem verder aan te scherpen.

Een kortere levensduur van certificaten verkleint de periode waarin een onrechtmatig certificaat kan worden misbruikt. Strengere regels voor het hergebruik van domeinvalidaties moeten voorkomen dat een aanvaller langdurig profiteert van een eerder succesvol uitgevoerde controle.

Daarnaast blijven Certificate Transparency, geautomatiseerde monitoring en DNS-beveiliging belangrijke verdedigingslagen.

Voor organisaties betekent dit dat het niet langer voldoende is om alleen te controleren of een website technisch bereikbaar is. Ook moet worden gecontroleerd welke certificaten voor de eigen domeinen worden uitgegeven, welke DNS-records actief zijn en wie wijzigingen aan die infrastructuur kan uitvoeren.

Wat organisaties hiervan kunnen leren

De belangrijkste les is dat een domeinkaping niet alleen een probleem is voor de website zelf.

Een succesvolle DNS-aanval kan ook gevolgen hebben voor:

• de uitgifte van HTTPS-certificaten;
• de betrouwbaarheid van browserverbindingen;
• phishing en identiteitsmisbruik;
• de reputatie van een organisatie;
• de vertrouwelijkheid van gebruikersgegevens;
• en de mogelijkheid om gebruikers naar kwaadaardige infrastructuur om te leiden.

Organisaties doen er daarom goed aan hun volledige domein- en DNS-infrastructuur als onderdeel van hun beveiligingsperimeter te behandelen.

Daarbij zijn onder meer de volgende maatregelen relevant:

1. Monitor alle Certificate Transparency-logs voor onverwachte certificaten.
2. Gebruik CAA-records om het aantal toegestane certificaatautoriteiten te beperken.
3. Beveilig registrar- en DNS-accounts met sterke authenticatie en zo beperkt mogelijke toegangsrechten.
4. Monitor DNS-wijzigingen en onderzoek onverwachte veranderingen onmiddellijk.
5. Houd een actueel overzicht bij van alle domeinen en subdomeinen die de organisatie gebruikt.
6. Controleer regelmatig welke certificaten actief zijn en of deze daadwerkelijk door de organisatie zijn aangevraagd.
7. Zorg voor een incidentresponsprocedure voor het geval DNS- of certificaatmisbruik wordt ontdekt.

Het incident rond de domeinen .gh, .sl en .as laat daarmee vooral zien dat een aanvaller niet altijd hoeft binnen te dringen in het netwerk van een bedrijf om zich als dat bedrijf voor te doen. Wanneer een vertrouwenslaag vóór de website wordt overgenomen, kan dat voldoende zijn om zelfs de beveiligingsmechanismen die gebruikers normaal tegen vervalste websites beschermen, tijdelijk in het voordeel van de aanvaller te laten werken.

Door: Drifter