Google: kaping ccTLD's leverde valse HTTPS-certificaten op

Google: kaping ccTLD's leverde valse HTTPS-certificaten op

Aanvallers die de controle over drie landcodedomeinen op het hoogste niveau in handen kregen, gebruikten die positie om HTTPS-certificaten te bemachtigen voor meerdere Google-domeinen en voor domeinen van andere grote organisaties. Google maakte de incidenten dinsdag bekend.

Het gaat om de extensies .gh (Ghana), .sl (Sierra Leone) en .as (Amerikaans-Samoa). Landcodedomeinen op het hoogste niveau, of ccTLD's, zijn de internetextensies van twee letters die aan landen en gebieden zijn toegewezen. Het dagelijkse beheer ligt vaak bij externe bedrijven en niet bij een overheidsinstantie. Volgens Google wisten de aanvallers die externe beheerders te compromitteren. Daarmee kregen ze greep op elk domein dat onder de drie extensies is geregistreerd, waarna ze de gezaghebbende DNS-records aanpasten.

Gezaghebbende DNS-records zijn het officiele antwoord op de vraag waar een domein zich op internet bevindt. Wie ze beheert, kan verkeer omleiden en in veel gevallen een certificaatautoriteit ervan overtuigen dat hij de eigenaar van het domein is.

Google: eigen systemen niet gehackt

Google benadrukte dat de aanvallers nooit binnen zijn infrastructuur zijn gekomen.

"Bij deze incidenten zijn de systemen van Google niet gecompromitteerd", aldus het bedrijf.

Ook de organisaties die de certificaten uitgaven, worden vrijgepleit. "Gezien de aard van de aanvallen hebben we geen reden om aan te nemen dat de certificaatautoriteiten (CA's) die de betreffende certificaten hebben uitgegeven, iets verkeerd hebben gedaan", voegde Google eraan toe.

Dat is het ongemakkelijke deel van dit incident. Certificaatautoriteiten (CA's) geven certificaten uit nadat ze hebben gecontroleerd of de aanvrager het domein beheert, een proces dat domain control validation (DCV) heet. Heeft een aanvaller de DNS in handen, dan kunnen die controles slagen terwijl de aanvraag frauduleus is. De CA's volgden de procedure, en de procedure gaf het verkeerde antwoord.

Google kwam vorige week achter de kapingen. Het bedrijf zei niet hoe de registerbeheerders zijn gecompromitteerd, wie achter de aanvallen zit en wanneer de activiteit begon.

Zo blokkeerde Chrome de certificaten

Voor de certificaten die betrekking hadden op zijn eigen diensten, stuurde Google blokkades naar Chrome via CRLSets. Dat is een lijst met ingetrokken certificaten die de browser ongemerkt op de achtergrond downloadt. Zo kan Google foute certificaten uitschakelen zonder op een volledige nieuwe browserversie te hoeven wachten.

Daarnaast werkte Google samen met de uitgevende CA's om de certificaten formeel in te trekken. Die stap is belangrijk voor iedereen die geen Chrome gebruikt, want een intrekking door de CA werkt ook door in andere browsers en clients.

Vervolgens dook het bedrijf in de Certificate Transparency-logs (CT-logs). Dat zijn openbare registers van uitgegeven certificaten waaraan alleen iets kan worden toegevoegd, bedoeld om domeineigenaren en onderzoekers certificaten te laten opsporen die ze niet zelf hebben aangevraagd. De CT-gegevens wezen op andere organisaties die volgens Google slachtoffer zijn van dezelfde campagne, waaronder een aantal grote internationale merken en populaire onlinediensten. Google noemde geen namen. Ook die certificaten werden in Chrome geblokkeerd en waar mogelijk nam Google contact op met de getroffen organisaties.

"Chrome-gebruikers hoeven niets te doen om beschermd te zijn", schreef Google. Net als bij reguliere beveiligingsupdates voor browsers zorgt een bijgewerkte Chrome ervoor dat de nieuwste beschermingen actief zijn.

Grenzen van de aanpak

Google waakte ervoor de oplossing mooier voor te stellen dan ze is. Het bedrijf waarschuwde dat het blokkeren van certificaten in de browser niet de enige verdedigingslinie mag zijn. Omdat DNS-kapingen complex zijn, "kunnen we niet garanderen dat onze analyse elk getroffen domein aan het licht heeft gebracht", aldus Google.

Ook wees het erop dat de ingrepen in Chrome mensen die andere browsers gebruiken niet betrouwbaar beschermen.

Google zegt in de toekomst met de bredere gemeenschap te blijven samenwerken om de schade te beperken die gecompromitteerde DNS en routering kunnen aanrichten.

"Om onze gebruikers veilig te houden, zetten we ons in voor structurele verbeteringen van het HTTPS-ecosysteem, zoals een kortere geldigheidsduur van certificaten en minder hergebruik van DCV, via het Chrome Root Program en het nieuwe Chrome Quantum-resistant Root Program", besloot het bedrijf.

Het grotere plaatje

Dit incident laat zien hoezeer de beveiliging van het web op DNS leunt. Een hangslotje in de adresbalk bewijst dat er een certificaat voor een domein is uitgegeven. Het bewijst niet dat de juiste partij erom heeft gevraagd. Wanneer de registerlaag boven een domein wordt gecompromitteerd, kunnen zelfs goed georganiseerde bedrijven als Google geldig ogende certificaten op hun naam uitgegeven zien worden, zonder dat hun eigen netwerken zijn gehackt.

Voor verdedigers is de praktische les dat ze CT-logs in de gaten moeten houden op certificaten voor hun domeinen. Zo vond Google de andere slachtoffers, en organisaties kunnen hetzelfde doen. Bedrijven die voor regionale sites of korte links gebruikmaken van ccTLD's waar minder streng op wordt toegezien, doen er goed aan zich af te vragen of de beheerder achter die extensie hetzelfde vertrouwen verdient als hun eigen infrastructuur.

Dat Google verwijst naar kortere looptijden van certificaten en minder hergebruik van DCV, doet vermoeden dat het bedrijf langlopende validaties ziet als een manier waarop de impact van dit soort kapingen wordt verlengd. Het nieuwe quantumbestendige rootprogramma past bovendien in een bredere verschuiving naar post-quantumcryptografie, die ook elders te zien is, zoals bij de post-quantumhandtekeningen van OpenSSH.

Het is de moeite waard om te volgen of de registerbeheerders bekendmaken hoe ze zijn gehackt, of de andere getroffen merken naar buiten treden en of andere browsermakers Chrome volgen met eigen blokkades.