Gekaperte ccTLDs: Gefälschte TLS-Zertifikate für Google

Unbekannte haben mehrere Ländercode-Top-Level-Domains gekapert und darüber regulär ausgestellte, aber unautorisierte TLS-Zertifikate für Google- und YouTube-Domains erhalten. Betroffen sind die ccTLDs .gh (Ghana), .sl (Sierra Leone) und .as (American Samoa). Der Fall wurde zunächst über Golem Security bekannt. Er zeigt, dass die Vertrauenskette bei HTTPS-Zertifikaten nur so stark ist wie die schwächste beteiligte Registry.

Gekaperte ccTLDs hebeln die Domain-Validierung aus

Der Angriff zielte nicht direkt auf Google, sondern auf die Betreiber der drei Länderendungen. Wie Ars Technica und The Register bestätigen, starteten die Angreifer eine Serie von Hijackings gegen die Third-Party-Registries der ccTLDs .gh, .sl und .as und änderten dort autoritative DNS-Einträge. Damit stand der Mechanismus zur Domain-Control-Validation unter ihrer Kontrolle.

Bei Domain-validierten Zertifikaten prüft eine CA lediglich, ob der Antragsteller Kontrolle über die angefragte Domain hat. Das geschieht häufig über einen DNS-Eintrag. Wer das autoritative DNS der TLD kontrolliert, kann für jede Domain unter dieser Endung die erwarteten Prüfwerte ausliefern. Die Zertifizierungsstelle sieht dann eine formal korrekte Bestätigung – ohne zu erkennen, dass die Prüfung selbst manipuliert wurde.

Zwölf Zertifikate für sieben Domains von Let’s Encrypt und ZeroSSL

Details aus den Certificate-Transparency-Logs dokumentiert The Hacker News: Zwischen dem 22. und 27. September wurden mindestens zwölf Zertifikate für sieben Domains ausgestellt. Darunter befinden sich google.com.gh, google.sl und google.as. Elf Zertifikate stellte Let’s Encrypt aus, eines ZeroSSL.

Die zeitliche Staffelung spricht für ein geplantes Vorgehen: Zuerst wurde am 22. September die Endung .gh missbraucht, am 25. September folgte .sl, am 27. September .as. Betroffen sind ausschließlich Domain-validierte Zertifikate, also solche, bei denen keine Organisationsprüfung stattfindet. Auch Domains weiterer großer Organisationen sollen betroffen sein. In den vorliegenden Quellen ist allerdings nicht belegt, ob über die Zertifikate tatsächlich Traffic umgeleitet oder Zugangsdaten abgegriffen wurden.

Google selbst sieht die eigenen Systeme nicht als kompromittiert an. Gegenüber Help Net Security erklärte das Unternehmen, die Vorfälle hätten keine Kompromittierung von Google-Systemen umfasst. Auch den ausstellenden CAs wird laut Google kein Fehlverhalten vorgeworfen.

Chrome blockiert per CRLSet – was Administratoren wissen sollten

Google hat die Zertifikate in Chrome über CRLSets blockiert und bei den ausstellenden CAs widerrufen lassen. Ein CRLSet ist ein im Browser mitgelieferter Notfall-Widerrufsmechanismus, mit dem Chrome einzelne Zertifikate sofort sperren kann, ohne auf eine reguläre Online-Prüfung warten zu müssen.

Einen klassischen Software-Patch gibt es in diesem Fall nicht. Es handelt sich nicht um eine Schwachstelle in einem Produkt, sondern um den Missbrauch des Zertifizierungsprozesses. Administratoren, die eigene Domains unter .gh, .sl oder .as betreiben, sollten prüfen, ob für ihre Namen unautorisierte Zertifikate ausgestellt wurden. Konkrete Workarounds nennen die Quellen bislang nicht.

Ein strukturelles Problem des Web-PKI-Modells

Der Fall macht eine grundlegende Schwäche sichtbar: Domain-validierte Zertifikate sind nur so vertrauenswürdig wie die DNS-Infrastruktur, auf der ihre Ausstellung beruht. Gelingt es Angreifern, eine Registry zu übernehmen, erhalten sie potenziell gültige Zertifikate für beliebige Domains unter dieser Endung – ohne die eigentlichen Domaininhaber zu kompromittieren.

Als Gegenmaßnahme setzen CAs zunehmend auf Multi-Perspective Issuance Corroboration. Dabei wird die Domainkontrolle aus mehreren Netzperspektiven geprüft, um punktuelle DNS-Manipulationen besser zu erkennen. Ob der aktuelle Vorfall zu zusätzlichen Anforderungen im Chrome Root Program führt, ist in den vorliegenden Quellen nur als Ankündigung angedeutet; Details fehlen bislang.

Fazit

Der Missbrauch der drei Länderendungen ist kein typischer Angriff auf eine Softwarelücke, sondern ein Angriff auf die Vertrauensinfrastruktur des Webs. Google hat schnell reagiert und die betroffenen Zertifikate in Chrome blockiert sowie widerrufen lassen. Offen bleibt, wie lange die Registries unkontrolliert manipuliert wurden und ob ähnliche Angriffe unbemerkt blieben. Für Sicherheitsteams ist der Vorfall ein Anlass, die Ausstellung von Zertifikaten für eigene Domains über Certificate-Transparency-Logs regelmäßig zu überwachen.

Quellen