Chrome sperrt Zertifikate nach Hijacks der .gh-, .sl- und .as-Registrierungen

Das Chrome-Team von Google griff letzte Woche ein, um unbefugte HTTPS-Zertifikate zu sperren, die für Domains unter den Endungen .gh, .sl und .as ausgestellt wurden. Der Browser-Anbieter reagierte, nachdem Angreifer diese spezifischen länderspezifischen Top-Level-Domain-Registrierungen (ccTLD) kompromittiert hatten. Dies ermöglichte es ihnen, DNS-Einträge zu ändern und gültige Zertifikate für gezielt ausgewählte Websites anzufordern. Dieser Vorfall unterstreicht die Fragilität des globalen Domain Name Systems und die kritische Notwendigkeit einer proaktiven Zertifikatsüberwachung durch Domain-Inhaber.

Was passiert ist

Die Sicherheitsverletzung ging nicht vom Google-Infrastruktur aus, sondern betraf die ccTLD-Registrierungen Dritter für Ghana (.gh), Sierra Leone (.sl) und Amerikanisch-Samoa (.as). Angreifer erlangten die Kontrolle über diese Registrierungen und änderten autoritative DNS-Einträge. Mit der Kontrolle über das DNS konnten sie die von Zertifizierungsstellen (CAs) erforderlichen Domain-Validierungsprüfungen bestehen. Folglich erhielten die Angreifer unbefugte HTTPS-Zertifikate für mehrere Google-Domains sowie für Domains anderer Organisationen.

Nach Erkennung der Anomalie setzte das Secure Web and Networking Team von Chrome sofort CRLSets ein, um die Nutzung dieser unbefugten Zertifikate im Chrome-Browser zu blockieren. CRLSets sind ein Mechanismus, den Chrome verwendet, um Zertifikate zu widerrufen, die technisch noch gültig sind, aber als kompromittiert oder fehlerhaft ausgestellt bekannt sind. Das Team koordinierte sich auch mit den ausstellenden CAs, um sicherzustellen, dass die Zertifikate formell widerrufen wurden, was Nutzer in anderen Browsern schützt. Chrome erklärte, dass es keine Hinweise darauf gab, dass die CAs selbst falsch gehandelt hätten; sie stellten Zertifikate basierend auf den manipulierten DNS-Daten aus, die von den Angreifern bereitgestellt wurden.

Weitere Analysen öffentlicher Certificate Transparency (CT)-Protokolle zeigten, dass die Angriffsfläche größer war als zunächst angenommen. Mehrere führende globale Marken und weit verbreitete Online-Dienste waren ebenfalls von denselben Registrierungshijacks betroffen. Chrome blockierte proaktiv Zertifikate für diese zusätzlichen Entitäten, um Nutzer zu schützen, während man versuchte, die betroffenen Organisationen zu kontaktieren. Der Browser-Anbieter betonte, dass Chrome-Nutzer keine manuellen Maßnahmen ergreifen mussten, da die Schutzmaßnahmen automatisch angewendet wurden.

Wichtige Details

• Betroffene Namensräume: Die Hijacks zielten speziell auf die ccTLDs .gh (Ghana), .sl (Sierra Leone) und .as (Amerikanisch-Samoa).
• Angriffsvektor: Die Kompromittierung von ccTLD-Registrierungen Dritter ermöglichte es Angreifern, autoritative DNS-Einträge zu ändern.
• Ergebnis: Angreifer erhielten unbefugte HTTPS-Zertifikate für Google- und andere Organisationsdomains.
• Reaktion von Chrome: Unbefugte Zertifikate wurden über CRLSets blockiert, und die ausstellenden CAs wurden für den Widerruf kontaktiert.
• Breitere Auswirkungen: Certificate Transparency-Protokolle zeigten, dass zusätzliche globale Marken und Dienste wahrscheinlich betroffen waren.
• Rolle der CAs: Google fand keine Hinweise darauf, dass die Zertifizierungsstellen bei der Ausstellung unsachgemäß handelten.

Hintergrund

Um diesen Vorfall zu verstehen, ist es hilfreich zu wissen, wie HTTPS-Zertifikate ausgestellt werden. Wenn ein Website-Inhaber ein Zertifikat anfordert, muss die CA verifizieren, dass der Antragsteller die Kontrolle über die Domain besitzt. Dies geschieht oft durch die Prüfung von DNS-Einträgen. Wenn ein Angreifer die Registrierung kontrolliert, die diese DNS-Einträge verwaltet, kann er Validierungsprüfungen auf seine eigenen Server umleiten und die CA dazu bringen, ein Zertifikat auszustellen. Dies wird als DNS-Hijack bezeichnet.

Certificate Transparency (CT) ist ein öffentliches Ledger-System, das entwickelt wurde, um solche Fehl-Ausstellungen zu erkennen. Jede vertrauenswürdige CA muss jedes ausgestellte Zertifikat in diesen öffentlichen Protokollen protokollieren. Dies ermöglicht es Domain-Inhabern und Browsern, nach Zertifikaten zu suchen, die ohne ihr Wissen ausgestellt wurden. In diesem Fall waren CT-Protokolle entscheidend dafür, das volle Ausmaß des Angriffs über Googles eigene Properties hinaus aufzudecken. CRLSets sind meanwhile eine Chrome-spezifische Funktion, die es Google ermöglicht, Notfall-Widerrufe schneller an Browser zu verteilen als den standardmäßigen globalen Widerrufsprozess.

Warum das wichtig ist

Für Teams, die ihre eigene Software betreiben oder Unternehmensdomains verwalten, dient dieser Vorfall als deutliche Erinnerung daran, dass Sie die Sicherheit Ihrer Domain nicht vollständig kontrollieren, wenn Sie sich nur auf das Standardverhalten der CAs verlassen. Selbst wenn Ihre internen Systeme sicher sind, kann eine Kompromittierung auf Registrierungsebene dazu führen, dass gültige Zertifikate für Ihre Domain ausgestellt werden. Diese Zertifikate können für Man-in-the-Middle-Angriffe verwendet werden, um Nutzerverkehr abzufangen und Anmeldedaten zu stehlen. Sich darauf zu verlassen, dass Browser-Anbieter wie Google diese Probleme erkennen, ist riskant, da deren Interventionen möglicherweise nicht alle Browser oder jede betroffene Domain abdecken.

Darüber hinaus bedeutet die Abhängigkeit von DNS für die Validierung, dass jede Schwäche in der Vertrauenskette – vom Registrar bis zur Registrierung – Ihre HTTPS-Sicherheit untergraben kann. Für selbst gehostete Anwendungen, bei denen Sie Ihr eigenes DNS und Ihre Zertifikate verwalten, ist es entscheidend, die externen Abhängigkeiten zu verstehen. Wenn Ihre Domain auf einer kompromittierten TLD gehostet wird, können Ihre internen Sicherheitsmaßnahmen umgangen werden, bevor der Traffic Ihren Server überhaupt erreicht. Proaktive Überwachung ist nicht mehr optional; sie ist eine notwendige Verteidigungsschicht gegen systemische Infrastrukturfehler.

Was Sie tun können

• Überwachen Sie Certificate Transparency-Protokolle: Richten Sie automatisierte Überwachungen für alle Ihre Domains ein, um Warnungen zu erhalten, wann immer ein neues Zertifikat ausgestellt wird. Dies bietet eine nahezu Echtzeit-Erkennung unbefugter Ausstellungen.
• Veröffentlichen Sie restriktive CAA-Einträge: Verwenden Sie Certification Authority Authorization (CAA)-DNS-Einträge, um genau festzulegen, welche CAs berechtigt sind, Zertifikate für Ihre Domains auszustellen. Dies begrenzt die Angriffsfläche, selbst wenn das DNS kompromittiert wird.
• Binden Sie ACME-Konten in CAA ein: Wo unterstützt, beschränken Sie die Zertifikatsausstellung auf spezifische ACME-Konto-Bindungen. Dies verhindert, dass Angreifer zwischengespeicherte Validierungsdaten nutzen, um neue Zertifikate zu prägen, nachdem sie die DNS-Kontrolle wiedererlangt haben.
• Prüfen Sie regionale ccTLDs: Wenn Sie Domains unter .gh, .sl oder .as oder anderen regionalen Endungen betreiben, überprüfen Sie sofort aktuelle CT-Protokolleintragungen auf unerwartete Aktivitäten.
• Auditieren Sie Ihr Domain-Portfolio: Stellen Sie sicher, dass Ihre Überwachung alle Domains abdeckt, einschließlich geparkter oder Legacy-Properties, da Angreifer oft weniger überwachte Assets ins Visier nehmen.
• Verlassen Sie sich nicht nur auf Browser-Blockaden: Implementieren Sie Ihre eigenen Erkennungs- und Reaktionsfähigkeiten, da browserseitige Interventionen nicht garantieren, dass Nicht-Chrome-Nutzer geschützt sind oder jeder Vorfall erkannt wird.