Ausnutzung von Schwachstellen
Acht kompromittierte eMudhra-CA-Zwischenschlüssel
Acht Zwischenschlüssel des CA-Ausstellers eMudhra sind kompromittiert worden. Wir zeigen, welche Risiken dabei entstanden sind und welche Schritte erforderlich sind, um Missbrauch aufzudecken und die Sicherheitslücke zu schließen
Save to Folio
Wichtigste Erkenntnisse
- Acht private Schlüssel der Zwischenzertifizierungsstelle (CA) von eMudhra, einem in Indien ansässigen CA-Aussteller, sind kompromittiert worden. Sechs dieser CAs können TLS-Zertifikate für Websites ausstellen, zwei davon Code-Signing-Zertifikate. Bis zu ihrer Sperrung waren alle acht mit Root-Zertifikaten verknüpft, Basis für die gängigen Browser und Betriebssysteme.
- Chrome, Firefox, Apple und Microsoft haben die Zertifikate gesperrt, und eMudhra hat sie am 18. Oktober widerrufen. Vor der Sperrung durch Chrome waren in den „Certificate Transparency“-Protokollen keine von den sechs TLS-Zwischenzertifikaten aufgetaucht.
- Das Risiko liegt nun bei Software, die nicht auf den Widerruf von Zertifikaten prüft: Linux-Distributionen, Laufzeitumgebungen für Programmiersprachen, Container, IoT-Geräte und Anwendungen, die ihre eigene Kopie der vertrauenswürdigen Root-Zertifikate mitliefern.
- Ein Angreifer müsste dennoch den Datenverkehr abfangen, um ein gefälschtes Website-Zertifikat nutzen zu können. Bei der Codesignierung verhält es sich anders. Eine Binärdatei, die mit einem der beiden Codesignatur-Zwischenzertifikate signiert wurde, könnte für jedes System, das noch nicht aktualisiert wurde, legitim erscheinen, und die für diese Zertifikate vermerkten Sperrdaten könnten dazu führen, dass ältere Signaturen weiterhin gültig bleiben.
Am 17. Oktober 2026 meldete ein Forscher, der sich „Wayne“ nannte, den Browser-Root-Programmen, dass er im Besitz von acht Zwischen-CA-Schlüsseln von eMudhra sei. Als Beweis signierte er die Nachricht „We have a problem here – Wayne“ mit jedem Schlüssel. Das Chrome-Root-Programm sperrte nach der Meldung die sechs TLS-Zwischenzertifikate innerhalb einer Stunde. Auch Mozilla sperrte alle acht Zertifikate in Firefox. eMudhra widerrief die acht Zertifikate am nächsten Tag, und Apple sperrte sie einen Tag später, gefolgt von Microsoft.
Mozilla machte den Sicherheitsvorfall am 20. Oktober in seinem „dev-security-policy“-Forum publik und veröffentlichte gleichzeitig eine Informationsseite, auf der die betroffenen Zertifikate und die gepatchten Softwareversionen aufgelistet sind.
Die betroffenen Zwischenzertifikate sind:
- EM DV TLS CA – G3B und EM DV TLS CA – G3C
- EM OV TLS CA – G3B und EM OV TLS CA – G3C
- EM EV TLS CA – G3B und EM EV TLS CA – G3C
- EM OV CS CA – G3B und EM OV CS CA – G3C (Code-Signierung)
Jedes existiert zudem als zweites Zertifikat mit demselben Schlüssel, gegensigniert von der seit langem etablierten Sectigo AAA Certificate Services-Root-Zertifizierungsstelle. Daher reicht das Entfernen der eMudhra-eigenen Root-Zertifikate aus einem Trust Store allein nicht aus. Ein System, das der Sectigo-Root weiterhin vertraut, kann die gegensignierten Kopien nach wie vor validieren.
In einem vorläufigen Bericht im Bug-Tracker von Mozilla führte eMudhra die schwachen Schlüssel auf einen Fehler im Skript zurück, das während einer Schlüsselzeremonie am 30. April 2025 verwendet wurde, in Verbindung mit menschlichem Versagen. Durch einen Testschritt entstand ein zweiter, schwächerer Schlüsselsatz, und diese Schlüssel wurden versehentlich zur Beantragung der Zertifikate verwendet. eMudhra gibt an, dass aus diesen Zwischenschlüsseln niemals Zertifikate ausgestellt wurden und dass die Code-Signing-Zertifizierungsstellen nie in den Produktivbetrieb übernommen wurden. Mozilla und Chrome entfernen nun die „emSign ECC Root CA – G3“ von eMudhra aus ihren Root Stores.
Mehr als nur ein Browser-Problem
Browser konnten das Problem schnell beheben, da sie Widerrufs-Updates direkt erhalten. Bei einem Großteil der auf TLS angewiesenen Software ist dies jedoch nicht der Fall. Befehlszeilen-Tools, Skripts, Container, eingebettete Geräte und Anwendungen, die mit Go, Python, Node.js, Rust oder Electron erstellt wurden, validieren Zertifikate häufig anhand einer mitgelieferten oder der Root-Liste des Betriebssystems und überprüfen niemals den Widerrufsstatus. Diese Systeme vertrauen einem mit den kompromittierten Schlüsseln ausgestellten Zertifikat so lange, bis jemand sie aktualisiert – und viele werden lange Zeit nicht aktualisiert werden.
Die Verwendung eines gefälschten TLS-Zertifikats erfordert eine „Man-in-the-Middle“-Position, das heißt die Kontrolle über ein vom Opfer genutztes Netzwerk, einen kompromittierten Router, einen betrügerischen WLAN-Zugangspunkt oder Zugriff auf der Ebene eines Internetdienstanbieters oder einer Regierungsbehörde. Dies schränkt ein, wer diese Schwachstelle ausnutzen kann. Doch die Gruppen, die dies können, sind genau diejenigen, vor denen sich die meisten Organisationen fürchten. Der Datenverkehr von VPN-Clients, Update-Agenten, APIs und Machine-to-Machine-Verbindungen ist am stärksten gefährdet, da er nicht über einen Browser läuft.
Das Risiko der Codesignierung
Ein mit einem dieser Schlüssel ausgestelltes Codesignierungszertifikat würde es einem Angreifer ermöglichen, Malware zu signieren, die sich an eine vertrauenswürdige Root-Zertifizierungsstelle anfügen lässt, ohne dass dabei Datenverkehr abgefangen werden muss. Betriebssysteme, Anwendungs-Whitelists und Sicherheits-Tools behandeln Software von einem verifizierten Herausgeber mit größerem Vertrauen – genau aus diesem Grund sind Angreifer auf Signaturen scharf.
Die Analyse von drei Millionen Software-Downloads durch unser FTR-Team 2018 ergab, dass dieselben Zertifikatsaussteller sowohl hinter legitimer als auch bösartiger Software standen, wobei die Zertifikate entweder gestohlen oder im Untergrund weiterverkauft wurden. Im Juni und Juli 2022 wechselten die Betreiber von QAKBOT zwischen nicht weniger als sieben legitimen Code-Signing-Zertifikaten, und im selben Jahr konnten wir drei gestohlene Code-Signing-Zertifikate mit den Kernel-Treibern einer Purple-Fox-Kampagne in Verbindung bringen. 2023 verwendeten BlackCat-Ransomware-Partner einen Kernel-Treiber, der Sicherheitsagenten beendet und den sie mit einem gestohlenen oder geleakten Cross-Signing-Zertifikat signiert hatten, um nur einige Beispiele zu nennen.
In jedem dieser Fälle war jeweils nur ein Zertifikat betroffen. Der eMudhra-Hack geht noch einen Schritt weiter. Wer im Besitz dieser Schlüssel ist, könnte beliebig viele Code-Signing-Zertifikate im Namen beliebiger Unternehmen ausstellen, und die Schlüssel waren schwach genug, um sie aus den öffentlichen Zertifikaten wiederherstellen zu können.
Auch Widerruf schließt die Lücke möglicherweise nicht vollständig. In den Widerrufslisten der Zertifikate sind der 18. und 19. Oktober 2026 als Sperrdaten für die Code-Signing Zwischenzertifikate vermerkt, während die schwachen Schlüssel aus dem April 2025 stammen. Wenn jedoch als Sperrdatum der Tag festgelegt wird, an dem ein Problem gemeldet wurde, können Signaturen mit einem Zeitstempel vor diesem Tag weiterhin als gültig erkannt werden. In diesem Fall hat die Zertifizierungsstelle das Datum auf unsere Anfrage hin nach hinten verschoben.
eMudhra gibt an, dass die Code-Signing Zwischenzertifikate nie in Produktion gegangen sind, sodass legitime Software, die mit ihnen signiert wurde, selten oder gar nicht vorhanden sein dürfte. Daher lohnt es sich, jede Binärdatei zu untersuchen, die eine Verknüpfung zu diesen Zertifikaten aufweist.
Maßnahmen für Unternehmen
Einzelheiten zu den unten genannten Maßnahmen liefert auch der Originalbeitrag.
- Aktualisieren Sie die Trust Stores überall, nicht nur auf Desktops. Patchen Sie zuerst Betriebssysteme und Browser, dann das „ca-certificates“-Paket auf Linux-Servern sowie Container-Basis-Images, Sprach-Runtimes und -Bibliotheken sowie alle Anwendungen, die eigene Stammzertifikate bündeln.
- Erstellen Sie die mit den alten Root-Zertifikaten erstellten Programme neu. Go kompiliert das Trust Handling in jedes Programm mit ein, daher müssen Go-Anwendungen mit einer gepatchten Version neu kompiliert werden. Container-Images behalten den Trust Store bei, mit dem sie erstellt wurden. Erstellen Sie sie daher aus einem aktualisierten Basis-Image neu. In beiden Fällen reicht eine Aktualisierung des Hosts nicht aus. Bei Anwendungen von Drittanbietern, die ihre eigenen Root-Zertifikate bündeln, muss der Fix vom Anbieter kommen.
- Testen Sie, was den Schlüsseln noch vertraut. Die Offenlegungs-Site betreibt 12 Test-Hosts, die Zertifikate der sechs TLS-Zwischenzertifikate sowohl über die eMudhra- als auch über die Sectigo-Kette bereitstellen. Testen Sie beide Ketten von jedem Server, Container oder Gerät aus, das Sie überprüfen. Ein Zertifikatsfehler ist das gewünschte Ergebnis. Wenn ein Test bestanden und der andere nicht bestanden wird, bedeutet dies, dass das System nur zur Hälfte korrigiert ist. Für Systeme, die Sie nicht direkt testen können, veröffentlicht die Website auch die Zertifikatsketten für Offline-Prüfungen.
- Entziehen Sie den Zwischenzertifikaten an TLS-Inspektions-Gateways das Vertrauen. Ein Gateway, das den Datenverkehr entschlüsselt, validiert das Zertifikat der Website im Namen des Benutzers und zeigt dem Browser ein Zertifikat an, das es selbst signiert hat. Wenn das Gateway diesen Zwischenzertifikaten weiterhin vertraut, leitet es ein gefälschtes Zertifikat als vertrauenswürdig an die Benutzer weiter, und der eigene Schutz des Browsers kommt nie zum Tragen. Die Korrektur des Gateways schützt jeden Nutzer, während die Geräte selbst gepatcht werden. Importieren Sie alle 16 Zertifikate, die in der Datei „affected-intermediates.json“ der Offenlegungs-Website aufgeführt sind, als ausdrücklich nicht vertrauenswürdig. Wenn Sie nur acht davon als nicht vertrauenswürdig einstufen, bleibt der Sectigo-Pfad offen. Stellen Sie das Gateway dann so ein, dass Zertifikate, die die Validierung nicht bestehen, blockiert werden. Stellen Sie schließlich über das Gateway eine Verbindung zu den Test-Hosts her, und überprüfen Sie das Ergebnis in den Protokollen des Gateways. Die Nutzer sehen in jedem Fall das Zertifikat des Gateways, sodass der Browser nicht anzeigt, ob die Korrektur funktioniert hat.
- Suchen Sie nach Missbrauch, beginnend mit den Systemen, bei denen eine Kompromittierung den größten Schaden anrichten würde. Beginnen Sie mit einer aktuellen Bestandsaufnahme der Assets und Identitäten, einschließlich der mit dem Internet verbundenen, und suchen Sie zunächst dort, wo ein gefälschtes Zertifikat oder eine signierte bösartige Binärdatei zu katastrophalen Schäden führen würde. Im Hinblick auf Identitäten und Berechtigungen sind dies Active Directory- und Microsoft Entra ID-Domänencontroller, Jump-Hosts für das Privileged Access Management (PAM) sowie Cloud-IAM-Rollen mit Administratorrechten. Bei besonders sensiblen Daten sind dies Produktionsdatenbanken mit personenbezogenen oder Gesundheitsdaten, Finanzabwicklungs-Pipelines, zentrale Quellcode-Repositorys und CI/CD-Build-Runner. Für das Infrastruktur-Backbone sind es die DNS-Infrastruktur, Hypervisoren und Kubernetes-Control-Planes sowie Schlüsselverwaltungssysteme. Innerhalb dieser Gruppen sollten Sie zunächst Systeme untersuchen, die den kompromittierten Zwischenzertifikaten noch vertrauen: nicht gepatchte Trust-Stores, veraltete Laufzeitumgebungen, eingebettete Geräte und Datenverkehr, der das Netzwerk verlässt, ohne einen aktualisierten Browser oder ein aktualisiertes Gateway zu durchlaufen. Durchsuchen Sie TLS-Inspektions-, Proxy- und Netzwerksensor-Protokolle nach Zertifikatsketten, die eines der acht Zwischenzertifikate enthalten.
- Überprüfen Sie, wem Sie standardmäßig vertrauen. Prüfen Sie, ob die von Ihnen verwalteten Systeme der Sectigo AAA Certificate Services-Root-Zertifizierungsstelle für Websites weiterhin vertrauen.
Wie TrendAI™ helfen kann
Die Vorgehensweise für die meisten Organisationen folgt der Reihenfolge der obigen Empfehlungen. TrendAI Vision One™ unterstützt jeden Schritt.
Entscheiden Sie, wo Sie suchen sollen. TrendAI Vision One™ Cyber Risk Exposure Management (CREM) bietet einen Überblick über die Angriffsfläche der Geräte, Konten, Anwendungen, Cloud-Ressourcen und internetexponierten Ressourcen des Unternehmens. Es weist jeder Ressource eine Kritikalitätsstufe zu, und Sicherheitsteams können die Kritikalität von Systemen erhöhen, von denen sie wissen, dass sie am wichtigsten sind, wie z. B. Domänencontroller, Schlüsselverwaltungssysteme oder Build-Server. So erhalten Sie eine nach Priorität geordnete Liste der Identitäts-, Daten- und Infrastruktursysteme, die zuerst überprüft werden sollten.
Suchen Sie dort, wo es darauf ankommt. Der XDR Data Explorer in TrendAI Vision One™ Agentic SIEM & XDR kann die Felder abfragen, die für beide Teile dieser Suche benötigt werden. Network Sensor, Virtual Network Sensor und Deep Discovery Inspector zeichnen den Namen des Zertifikatsausstellers und den Fingerabdruck für den ihnen sichtbaren TLS-Datenverkehr auf, sodass Analysten nach Zertifikaten suchen können, die von einem der sechs TLS-Zwischenzertifikate ausgestellt wurden. Der Endpoint Sensor zeichnet den Unterzeichner jedes Prozesses und jeder Datei auf, sodass Analysten nach Binärdateien suchen können, die unter „EM OV CS CA – G3B“ oder „G3C“ signiert wurden. Internet Access protokolliert eine aufgrund eines nicht vertrauenswürdigen Serverzertifikats blockierte Verbindung als eigenen Ereignistyp, wodurch jeder Versuch sichtbar wird, der das Gateway erreichte, nachdem die Zwischenzertifikate als „nicht vertrauenswürdig“ markiert wurden.
Erkennen Sie die Zertifikate im Netzwerk. Die Deep Discovery Inspector-Regel FAR584 erkennt die kompromittierten Zertifikate anhand ihres SHA-1-Hashwerts. Der integrierte CA-Speicher von Deep Discovery Inspector enthält „emSign ECC Root CA-G3“, die eMudhra-Stammzertifizierungsstelle, die Mozilla und Chrome derzeit entfernen, und ein kritischer Patch zur Aktualisierung des CA-Speichers steht zur Veröffentlichung bereit [22.10.].
Schließen Sie die Lücke am Gateway. Unternehmen, die eine TLS-Prüfung mit TrendAI Vision One™ Internet Access durchführen, können alle 16 Zertifikate unter den Einstellungen für Root- und Zwischenzertifikate als „nicht vertrauenswürdig“ hochladen und die Aktion für Zertifikate, die die Validierung nicht bestehen, von der Standardeinstellung „Warnung“ auf „Blockieren“ ändern. Kunden des Tipping Point Threat Protection System (TPS), die eine SSL-Prüfung nutzen, sollten die betroffenen Standard-Zertifizierungsstellen über die CLI als nicht vertrauenswürdig einstufen, bis ein Firmware-Update diese aus dem integrierten Speicher und dem installierbaren CA-Bundle entfernt.
Geben Sie es weiter. TrendAI Vision One™ Services – Managed Detection and Response (MDR) bietet rund um die Uhr verfügbare Erkennung, Untersuchung und Reaktion durch TrendAI™-Analysten, die mit derselben Vision One-Telemetrie arbeiten. Unternehmen, die wissen möchten, ob sie ins Visier genommen wurden, können eine TrendAI™-Kompromittierungsbewertung anfordern, und diejenigen, die glauben, dass sie Opfer eines Angriffs geworden sind, sollten sich an den TrendAI™-Incident-Response-Dienst wenden.
Anhang: Identifikatoren für die Suche