Gefälschte Google-Zertifikate: .gh, .sl und .as gekapert

Das kleine Schloss in der Adresszeile. Es sagt dir: Die Verbindung ist verschlüsselt, und die Gegenstelle hat bewiesen, dass sie diese Domain besitzt. Diese Woche hat Google erklärt, dass genau dieser Beweis bei mehreren Google-Domains an die Falschen ging. Angreifer haben sich echte, von Browsern anerkannte HTTPS-Zertifikate ausstellen lassen, ohne bei Google einzubrechen und ohne dass die Zertifizierungsstellen etwas falsch gemacht hätten. Der Trick lag eine Etage tiefer, bei der Verwaltung ganzer Länderendungen.

Was bei .gh, .sl und .as passiert ist

Jede Länderendung hat einen Betreiber, die Registry. Sie führt das Verzeichnis, welche Nameserver für welche Domain zuständig sind. Stell dir das Telefonbuch vor, in dem alle anderen Telefonbücher nachschlagen. Laut Googles Blogpost vom 6. Oktober haben Angreifer die Betreiber dreier solcher Endungen kompromittiert: .gh, .sl und .as. Googles eigene Formulierung dazu lautet, damit sei jede Domain mit diesen Endungen gefährdet gewesen.

Mit dem Telefonbuch in der Hand haben die Angreifer für ausgewählte Namen die Einträge geändert. Darunter waren, so Google, mehrere Google-Domains sowie Domains anderer Organisationen, die Google nur als führende Marken und viel genutzte Dienste umschreibt. Welche Namen genau, welche Zertifizierungsstellen, wie viele Zertifikate: Das sagt der Post nicht. Google nennt auch keine Täter.

Warum die Zertifizierungsstelle nichts falsch gemacht hat

Wenn du dir ein Zertifikat holst, etwa über Let's Encrypt für deinen Nginx Proxy Manager, prüft die Zertifizierungsstelle eine Sache: Kontrollierst du diese Domain? Dafür legt sie dir eine Aufgabe hin, zum Beispiel eine bestimmte Datei auf deinem Webserver oder einen bestimmten DNS-Eintrag. Diese Prüfung heißt Domain Control Validation, kurz DCV. Sie stellt keine Fragen nach Ausweis oder Firma. Sie fragt nur: Antwortet unter dieser Adresse jemand, der die Aufgabe lösen kann?

Genau das konnten die Angreifer. Wer das Verzeichnis kontrolliert, bestimmt, welcher Server unter dem Namen antwortet. Die Zertifizierungsstelle hat also nach Regelbuch gefragt, eine korrekte Antwort bekommen und ein korrektes Zertifikat ausgestellt. Google schreibt wörtlich, man habe keinen Grund zur Annahme, dass die ausstellenden Stellen etwas falsch gemacht hätten. Ich lese das nicht als Freispruch für das System, sondern als Beschreibung seiner Schwachstelle: Die ganze Kette hängt daran, dass das DNS die Wahrheit sagt. Und das DNS wird von Leuten betrieben, die man sich nicht aussucht.

Ein Detail aus dem Post macht die Sache zäher, als sie auf den ersten Blick wirkt. Zertifizierungsstellen dürfen eine bestandene Prüfung eine Zeit lang zwischenspeichern und für weitere Zertifikate wiederverwenden. Wer die Prüfung einmal bestanden hat, kann also nachlegen, auch wenn die Registry ihre Einträge längst repariert hat. Google kündigt an, über sein Root-Programm für Chrome sowohl die Laufzeit von Zertifikaten als auch diese Wiederverwendung zu verkürzen. Zahlen nennt der Post nicht.

Chrome sperrt per CRLSet, der Rest wartet auf den Widerruf

Google hat drei Dinge getan. Erstens die bekannten Zertifikate in die CRLSets eingetragen, das ist die Sperrliste, die Chrome regelmäßig selbst nachlädt, ohne dass du ein Update einspielen musst. Zweitens bei den Zertifizierungsstellen den formellen Widerruf veranlasst, damit auch andere Programme die Zertifikate ablehnen. Drittens die öffentlichen Certificate-Transparency-Logs durchsucht, in denen jedes ausgestellte Zertifikat protokolliert wird, und so weitere betroffene Organisationen gefunden und informiert.

Für Chrome-Nutzer heißt es im Post ausdrücklich, es sei nichts zu tun. Gleich dahinter steht der Satz, den ich für den ehrlichsten des ganzen Textes halte: Wegen der Komplexität solcher DNS-Entführungen könne Google nicht garantieren, jede betroffene Domain gefunden zu haben, und Chromes Eingriffe schützten Nutzer anderer Browser nicht zuverlässig.

Was du daraus machst: Firefox und Safari aktuell halten, mehr geht an der Stelle nicht. Und die Gefahr nüchtern einordnen. Ein erschlichenes Zertifikat allein richtet nichts an. Der Angreifer braucht zusätzlich einen Platz zwischen dir und Google, etwa über ein manipuliertes WLAN, einen gekaperten Router oder einen DNS-Server, den er kontrolliert. Für dich am heimischen Anschluss in Deutschland ist das kein Szenario, bei dem ich heute den Browser wechseln würde. Für Nutzer in Ghana oder Sierra Leone, deren Telefonbuch gerade in fremder Hand war, sieht die Rechnung anders aus.

Ein eigener Resolver wie Pi-hole mit Unbound hätte hier übrigens nicht geholfen, und das sage ich ungern. Unbound fragt die zuständigen Nameserver direkt, aber welche das sind, erfährt es aus dem Verzeichnis der Registry. War das manipuliert, bekommt auch der sauberste Resolver die falsche Antwort.

Eigene Domain? Dann CAA-Eintrag und crt.sh

Wer eine eigene Domain betreibt, und sei es nur für das Homelab, hat zwei Hebel, die Google in seinem Post selbst empfiehlt. Beide kosten keine zehn Minuten.

Erstens: ein CAA-Eintrag. Das ist ein DNS-Eintrag, in dem du festlegst, welche Zertifizierungsstellen überhaupt Zertifikate für deine Domain ausstellen dürfen. Jede Stelle muss ihn vor der Ausstellung prüfen. Holst du deine Zertifikate bei Let's Encrypt, sieht der Eintrag so aus:

deine-domain.de.  CAA  0 issue "letsencrypt.org"

Ob er sitzt, prüfst du von jedem Rechner aus:

dig CAA deine-domain.de +short

Ehrlich dazu: Gegen den Angriff aus dieser Woche hätte ein CAA-Eintrag allein nicht gereicht, denn wer das DNS kontrolliert, kann auch den CAA-Eintrag ändern. Google empfiehlt deshalb zusätzlich, den Eintrag an das eigene ACME-Konto zu binden, damit nur dein Client bei deiner Zertifizierungsstelle bestellen darf. Let's Encrypt unterstützt das laut seiner CAA-Doku über den Parameter accounturi; ob dein DNS-Anbieter solche Parameter im Eintrag erlaubt, steht in dessen Hilfe.

Zweitens: einmal nachsehen, was auf deinen Namen ausgestellt wurde. Die Certificate-Transparency-Logs sind öffentlich, und crt.sh macht sie durchsuchbar. Gib dort deine Domain ein. Jedes Zertifikat, das du nicht kennst, ist ein Grund, genauer hinzuschauen. Google rät, diese Logs dauerhaft zu beobachten, ausdrücklich auch für Domains, die nur geparkt sind. Für ein Homelab reicht mir ein Blick alle paar Monate und nach jedem Anbieterwechsel.

Was mich an dieser Geschichte am meisten beschäftigt, ist nicht Google. Google hat die Werkzeuge, so etwas innerhalb von Tagen zu sehen und zu sperren. Es sind die anderen Marken, die der Post nicht nennt, und die kleinen Domains unter .gh, .sl und .as, bei denen niemand die Logs liest. Für die gilt Googles eigener Satz: keine Garantie, dass alles gefunden wurde.

Hast du für deine Domain schon einen CAA-Eintrag gesetzt, oder war dir bis heute nicht klar, dass es den gibt? Schreib's in die Kommentare.

Wenn dich interessiert, wie Zertifikate im Homelab überhaupt an deine Dienste kommen, ist der Beitrag zum Reverse Proxy der passende Einstieg.

Quellen

• Google Security Blog: Chrome's Response to Recent ccTLD Registry Hijacks
• Help Net Security: Hackers hijack three country-code domain registries, obtain HTTPS certificates for Google domains
• CyberInsider: Google blocks rogue HTTPS certificates after domain registry hijacks
• Let's Encrypt: Certificate Authority Authorization (CAA)