DNS-Manipulation brachte Zertifikate für Google-Domains

Das Schloss neben einer Webadresse zeigt an, dass eine Zertifizierungsstelle, der der Browser vertraut, geprüft hat, ob der Antragsteller die Kontrolle über den Domainnamen nachweisen kann. Am 6. Oktober teilte Google mit, Angreifer hätten DNS-Einträge in den Länderendungen Ghanas (.gh), Sierra Leones (.sl) und Amerikanisch-Samoas (.as) verändert und dadurch vertrauenswürdige Zertifikate für mehrere Google-Domains sowie für Namen anderer Organisationen erhalten (Google). Nach Angaben des Unternehmens seien die eigenen Systeme nicht angegriffen worden; öffentliche Belege dafür, dass die Zertifikate gegen Besucher eingesetzt wurden, gebe es nicht.

Die Schwachstelle lag im DNS, dem System, das Domainnamen in Adressen übersetzt. Eine Anfrage wird dabei über mehrere Stellen weitergeleitet: Für eine beispielhafte Domain wie acme.gh verweist die .gh-Zone auf die Server, die für acme.gh zuständig sind; diese Server liefern dann die Adresse der Website. Ändert jemand diesen übergeordneten Verweis, werden Anfragen zu acme.gh an Server geleitet, die der Angreifer bestimmt (RFC 1034). Google hat nicht mitgeteilt, welche Einträge verändert wurden oder welche Registerbetreiber beziehungsweise Konten betroffen waren.

Wie ein manipuliertes Adressbuch zum Schloss führt

Bevor eine Zertifizierungsstelle ein Zertifikat ausstellt, muss sie prüfen, ob der Antragsteller den betreffenden Namen kontrolliert. Ein gängiges automatisiertes Verfahren nutzt dafür das DNS: Die Stelle gibt einen zufälligen Code vor und prüft, ob ein passender Eintrag im DNS des Domainnamens erscheint (RFC 8555). Das ist, als müsste jemand seinen Wohnsitz durch einen Brief nachweisen, der an diese Adresse geschickt wird.

Ein gekapertes DNS kann auf diese Weise zu einem Zertifikat führen, ohne dass jemand die Server des eigentlichen Domaininhabers anfasst. Es gibt weitere Prüfverfahren, darunter webbasierte Herausforderungen (Let's Encrypt); Google hat nicht mitgeteilt, welches Verfahren die Angreifer bestanden.

Google hält die Zertifikatsaussteller deshalb für regelkonform. Nach den Branchenregeln gilt eine erfolgreiche Prüfung als Beleg dafür, dass der Antragsteller den Namen kontrolliere (CA/Browser Forum). Gibt das DNS falsche Auskünfte, kann eine Zertifizierungsstelle also selbst dann ein gültiges Zertifikat an die falsche Partei ausstellen, wenn sie das vorgeschriebene Verfahren genau einhält.

Zwei gängige Schutzmaßnahmen zeigen, wie wichtig die Kontrolle über DNS-Antworten ist. DNSSEC versieht diese Antworten mit digitalen Signaturen, ähnlich einem manipulationssicheren Siegel. So kann der DNS-Dienst, über den ein Gerät Namen nachschlägt, prüfen, ob eine Antwort aus der erwarteten Vertrauenskette stammt. Das Siegel zeigt jedoch nicht, ob der Domaininhaber eine Änderung wollte: Eine Änderung, die eine gekaperte übergeordnete Stelle veröffentlicht, würde weiterhin als gültig gelten.

Mit CAA-Einträgen kann ein Domaininhaber festlegen, welche Zertifizierungsstellen Zertifikate für seine Namen ausstellen dürfen. Diese Liste liegt allerdings ebenfalls im DNS. Wer die Antworten dort kontrolliert, könnte sie grundsätzlich ändern (RFC 8659). Google hat nicht mitgeteilt, ob eine der beiden Schutzmaßnahmen für die betroffenen Namen eingerichtet war.

Chrome sperrt die Zertifikate

Google sperrte die von ihm identifizierten Zertifikate in Chrome mithilfe von CRLSets. Diese Sperrlisten verteilt der Browser selbst an seine Nutzer (Chromium). Anschließend durchsuchte Google die Certificate-Transparency-Protokolle. In diesen öffentlichen Verzeichnissen werden ausgestellte Zertifikate erfasst, ähnlich wie in einem für alle zugänglichen Grundbuch (Certificate Transparency). Dabei fand das Unternehmen weitere betroffene Namen, die es als führende globale Marken bezeichnete, ohne sie zu nennen.

Google zufolge kontaktierte das Unternehmen die erreichbaren Inhaber, sperrte deren Zertifikate in Chrome und arbeitete mit den Ausstellern daran, sie auch für andere Software zu widerrufen. Die Maßnahmen in Chrome schützten Nutzer anderer Browser nicht zuverlässig; außerdem könne Google nicht garantieren, alle betroffenen Domains gefunden zu haben.

Ein Zertifikat allein leitet niemanden auf eine Website. Um es auszunutzen, müsste ein Angreifer zusätzlich die Verbindungen von Nutzern zu einem Server lenken, der das Zertifikat vorzeigt. Google meldet weder eine gefälschte Website noch abgefangene Sitzungen oder gestohlene Zugangsdaten. Auch der Bericht von Ars Technica gibt Googles Erkenntnisse weitgehend wieder, bestätigt sie aber nicht unabhängig (Ars Technica). Öffentliche Belege dafür, dass die Zertifikate gegen Besucher eingesetzt wurden, gibt es nicht.

Der Vorfall zeigt, dass ein Schloss neben der Webadresse nur so verlässlich ist wie die DNS-Stelle, die über dem jeweiligen Namen steht — auch bei kleinen regionalen Endungen. Google rät Domaininhabern, die Certificate-Transparency-Protokolle fortlaufend für ihr gesamtes Portfolio zu überwachen, einschließlich ruhender und regionaler Domains. Dort würde ein Zertifikat, das sie nie angefordert haben, zuerst sichtbar (Google).