Wie ein Country-Code-Hijack die Vertrauenskette des Internets brach

Ich erinnere mich, wie ich 2011 in einem fensterlosen Rechenzentrum saß, als die Nachricht über DigiNotar bekannt wurde. Damals ermöglichte eine einzige kompromittierte Zertifizierungsstelle in den Niederlanden Angreifern, betrügerische Anmeldedaten für Google zu erstellen. Es fühlte sich wie ein fundamentaler Verrat an der Mathematik an, die das Internet sicher hält. Spulen wir vor ins späte Jahr 2026: Die Branche hat es mit einer Version desselben Albtraums zu tun, auch wenn sich der Einstiegspunkt verschoben hat. Ein milliardenschwerer Sicherheitsapparat wurde durch das digitale Äquivalent eines Schlossers besiegt, der die Generalschlüssel in einem Eisenwarenladen in einer Kleinstadt stiehlt.

Google bestätigte kürzlich, dass Angreifer drei länderspezifische Top-Level-Domains (ccTLDs) gekapert haben: .gh (Ghana), .sl (Sierra Leone) und .as (Amerikanisch-Samoa). Durch die Erlangung der Kontrolle über diese Namensräume änderten die Akteure die autoritativen DNS-Einträge für spezifische, hochwertige Ziele. Diese Kontrolle ermöglichte es ihnen, die automatisierten Validierungsprüfungen zu umgehen, die Zertifizierungsstellen zur Überprüfung der Inhaberschaft verwenden. Das Ergebnis war die Ausstellung nicht autorisierter TLS-Zertifikate für mehrere Google-Domains und andere große globale Marken. Dies ist das architektonische Paradoxon moderner Sicherheit: Ein Unternehmen kann Millionen für Zero Trust und Hardware-Sicherheitsschlüssel ausgeben, doch seine digitale Identität bleibt an die administrative Sicherheit eines fernen Registers gebunden.

Die Mechanik der Umgehung der Domain-Kontrolle

Um zu verstehen, warum dies geschah, müssen wir uns ansehen, wie eine Website beweist, wer sie ist. Wenn eine Organisation ein TLS-Zertifikat anfordert, muss die ausstellende Zertifizierungsstelle (Certificate Authority, CA) verifizieren, dass der Antragsteller die Domain tatsächlich kontrolliert. Der Industriestandard hierfür ist die Domain Control Validation (DCV). Die CA fordert den Antragsteller auf, eine bestimmte Aufgabe auszuführen, z. B. das Hosten einer eindeutigen Datei unter einer bestimmten URL oder, was häufiger vorkommt, das Erstellen eines spezifischen DNS-Eintrags. Wenn die CA den korrekten Eintrag auf den autoritativen Nameservern sieht, stellt sie das Zertifikat aus.

Bei diesem Vorfall mussten die Angreifer Google nicht hacken. Sie hackten die TLD-Infrastruktur selbst. Sobald sie die Nameserver für .gh, .sl und .as kontrollierten, leiteten sie die DNS-Einträge für die Ziel-Subdomains auf ihre eigenen Server um. Als die CA die automatisierte Prüfung durchführte, lieferte der Server der Angreifer die korrekte Antwort. Die CA befolgte ihr Protokoll perfekt, aber sie sprach mit einem Hochstapler. Das System ist ein digitaler Tresor, der nur funktioniert, wenn der Türsteher tatsächlich weiß, wie der echte Besitzer aussieht.

Warum Browser-Blockaden nur eine vorübergehende Lösung sind

Google hat Chrome aktualisiert, um diese nicht autorisierten Zertifikate sofort zu blockieren. Dies ist eine reaktive Maßnahme, die Millionen von Nutzern schützt, aber sie verdeutlicht eine systemische Schwäche. Der Prozess des Widerrufs eines Zertifikats ist bekanntermaßen langsam. Traditionelle Methoden wie Zertifikatssperrlisten (CRLs) oder das Online Certificate Status Protocol (OCSP) scheitern oft aufgrund von Datenschutzbedenken oder Netzwerklatenz. Infolgedessen sind Browserhersteller dazu übergegangen, fest kodierte Blocklisten zu verwenden, um sofortigen Schutz zu bieten.

Aus Risikoperspektive ist diese Intervention nur ein Pflaster. Google gab zu, dass Chrome-Interventionen Nutzer auf anderen Browsern nicht schützen und das Unternehmen nicht sicher sein kann, jede betroffene Domain identifiziert zu haben. Wenn ein Angreifer im Besitz eines gültig signierten Zertifikats ist, das ein Browser noch nicht blockiert hat, kann er einen Man-in-the-Middle-Angriff durchführen. Er kann den Datenverkehr abfangen, sensible Daten entschlüsseln und dem Opfer ein "sicheres" Vorhängeschloss-Symbol präsentieren. Die Integrität der Verbindung ist dahin, und der Nutzer hat keine Möglichkeit, den Unterschied zu erkennen.

Die dunkle Materie des Unternehmensnetzwerks

DNS ist oft die dunkle Materie der Unternehmenssicherheit. Es ist unsichtbar, allgegenwärtig und wird häufig übersehen, bis etwas kaputt geht. Viele Organisationen behandeln ihre TLD-Beziehungen als einfache Abrechnungsangelegenheit und nicht als geschäftskritische Sicherheitsabhängigkeit. Wenn Sie eine Domain in einer Länder-TLD registrieren, setzen Sie Ihr Vertrauen in die Registersicherheit dieser Nation, die Stabilität ihrer Regierung und ihre technische Widerstandsfähigkeit.

Mit Blick auf die Bedrohungslandschaft zeigt dieser Vorfall, dass sich Angreifer in der Lieferkette nach oben bewegen. Anstatt einen gehärteten Perimeter anzugreifen, zielen sie auf die dezentralen Komponenten der Kerninfrastruktur des Internets ab. Eine Sicherheitsverletzung auf TLD-Ebene ist heimlich, da sie keine internen Alarme auslöst. Die Server der Organisation sind in Ordnung, die Mitarbeiter klicken nicht auf Phishing-Links und die Firewall ist ruhig. Dennoch wird die Identität der Marke an anderer Stelle gefälscht.

Implementierung der Certification Authority Authorization

Google rät Domaininhabern, Certification Authority Authorization (CAA) DNS-Einträge als Gegenmaßnahme zu veröffentlichen. Ein CAA-Eintrag ist eine Richtlinienerklärung, die der Welt mitteilt, welche spezifischen CAs Zertifikate für eine Domain ausstellen dürfen. Wenn ein böswilliger Akteur versucht, ein Zertifikat von CA "A" zu erhalten, der CAA-Eintrag aber nur CA "B" auflistet, sollte die Anfrage abgelehnt werden.

CAA-Einträge sind jedoch nur wirksam, wenn sie restriktiv sind und wenn die CAs sie respektieren. Wichtiger noch: Wenn ein Angreifer das DNS kapert, kann er den CAA-Eintrag einfach löschen oder ändern, bevor er das betrügerische Zertifikat anfordert. Google deutet an, dass diese Einträge verhindern können, dass Angreifer zwischengespeicherte Validierungsdaten wiederverwenden, aber sie sind kein Allheilmittel. Sie sind ein granulares Werkzeug, das dem Angreifer eine zusätzliche Hürde in den Weg legt, aber sie verlassen sich immer noch auf die Integrität des DNS selbst.

Die Bedeutung von Certificate Transparency Logs

Hinter den Kulissen ist der effektivste Weg, diese Art von Aktivitäten zu erkennen, die Nutzung von Certificate Transparency (CT) Logs. CT ist ein System öffentlicher, nur anhängbarer Protokolle, die jedes von teilnehmenden CAs ausgestellte TLS-Zertifikat aufzeichnen. Jedes Mal, wenn ein Zertifikat für Ihre Domain erstellt wird, erscheint es in diesen Logs.

Proaktiv gesprochen sollte jedes Sicherheitsteam diese Logs für seine Domains überwachen. Wenn ein Zertifikat von einer CA erscheint, die Sie nicht verwenden, oder zu einem Zeitpunkt, an dem Sie keines angefordert haben, haben Sie es wahrscheinlich mit einem laufenden Hijack zu tun. Ich verwende mehrere automatisierte Tools, die mich via Signal benachrichtigen, sobald ein neues Zertifikat für ein von mir verwaltetes Objekt ausgestellt wird. Diese forensische Sichtbarkeit ist der einzige Weg, einen Hijack auf TLD-Ebene zu erkennen, bevor er zu einer massiven Datenpanne führt.

Lehren aus der DigiNotar-Ära

Dieser Vorfall ist eine Erinnerung daran, dass das Zertifikatssystem systemische Mängel aufweist. Im Jahr 2011 war der DigiNotar-Einbruch eine digitale Geiselnahme für die Menschen im Iran, deren Datenverkehr von ihrer Regierung mit gefälschten Zertifikaten abgefangen wurde. Während sich der aktuelle TLD-Hijack auf Marken und Dienste zu konzentrieren scheint, ist die technische Schwachstelle identisch. Wir verwenden immer noch ein zentralisiertes Vertrauensmodell in einer dezentralisierten Welt.

Verschlüsselung ist nur dann ein bruchsicherer digitaler Tresor, wenn die Schlüssel mit absoluter Integrität gehandhabt werden. Wenn die Infrastruktur, die diese Schlüssel validiert, kompromittiert ist, steht die Tresortür weit offen. Die Angreifer in diesem Fall haben gezeigt, dass man die Verschlüsselung nicht brechen muss, um zu gewinnen. Man muss das System nur davon überzeugen, dass man der rechtmäßige Besitzer des Tresors ist.

Praktische Erkenntnisse für Sicherheitsverantwortliche

Sicherheit bedeutet oft, Abhängigkeiten zu verwalten, die man nicht kontrolliert. Obwohl Sie die Infrastruktur eines ausländischen TLD-Registers nicht sichern können, können Sie kontrollieren, wie Ihre Organisation auf diese Risiken reagiert.

• Auditieren Sie Ihr Domain-Portfolio und identifizieren Sie, welche Domains unter ccTLDs mit weniger strengen Sicherheitsprotokollen registriert sind.
• Veröffentlichen Sie CAA-Einträge für alle geschäftskritischen Domains, um einzuschränken, welche Behörden Anmeldedaten ausstellen können.
• Richten Sie eine Echtzeit-Überwachung der Certificate Transparency Logs ein, um unbefugte Ausstellungen innerhalb von Minuten zu erfassen.
• Aktivieren Sie DNS Security Extensions (DNSSEC), wo immer möglich, um Ihre DNS-Daten mit kryptografischen Signaturen zu versehen und Hijacks zu erschweren.
• Überarbeiten Sie Ihren Incident-Response-Plan, um ein Protokoll für den schnellen Zertifikatswiderruf und die Koordination mit Browser-Herstellern aufzunehmen.

Als Gegenmaßnahme stellen diese Schritte sicher, dass Ihr Team selbst bei einem Ausfall des TLD-Registers die Sichtbarkeit hat, um zu reagieren, bevor der Schaden systemisch wird. Das Ziel ist der Übergang von einer reaktiven zu einer resilienten Haltung. Sicherheit ist kein Zustand, den man erreicht, sondern ein Prozess, den man aufrechterhält.

Quellen:

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Haftungsausschluss: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken und ersetzt kein professionelles Cybersicherheits-Audit oder einen Incident-Response-Service.