Schlüssel von eMudhra CA kompromittiert: Dringende Korrekturen für Browser und Laufzeitumgebungen erforderlich

Das Chrome Root Program von Mozilla und Google bestätigte am 20. Oktober, dass die privaten Schlüssel für acht Intermediate-Zertifikate der Zertifizierungsstelle (CA) eMudhra kompromittiert wurden. Dieser kritische Sicherheitsvorfall löste sofortige Notfallkorrekturen in den wichtigsten Webbrowsern und Software-Laufzeitumgebungen aus, um potenzielle Man-in-the-Middle-Angriffe zu verhindern. Der Vorfall wurde am 17. Oktober von einem Forscher gemeldet, was dazu führte, dass Chrome und Firefox innerhalb weniger Stunden nach der Verifizierung Blockiermaßnahmen einleiteten.

Was passiert ist

Im Kern dieses Vorfalls steht der Diebstahl oder unbefugte Zugriff auf private Schlüssel von eMudhra, einer indischen Zertifizierungsstelle, die digitale Zertifikate unter der Marke emSign ausstellt. Diese spezifischen Schlüssel gehören zu Intermediate-Zertifikaten, die verwendet werden, um Endentitätszertifikate für Websites und Software zu signieren. Der Besitz dieser privaten Schlüssel ermöglicht es einem Angreifer, gültige TLS-Zertifikate für jede Domain auszustellen, denen Browser normalerweise als legitim vertrauen würden. Die Kompromittierung betrifft sechs Intermediate-Zertifikate, die für die TLS-Verschlüsselung verwendet werden, sowie zwei für die Code-Signierung, wobei die Typen Domain Validated, Organization Validated und Extended Validation abgedeckt sind.

Ein Sicherheitsforscher, der sich nur als Wayne ausgab, meldete das Problem am Abend des 17. Oktober an die Betreiber der Root-Programme. Wayne demonstrierte den Besitz der Schlüssel, indem er eine Nachricht mit jedem der acht kompromittierten privaten Schlüssel signierte. Chrome überprüfte die Erkenntnisse und implementierte bis 19:45 UTC am 17. Oktober eine Sperre über seinen CRLSet-Mechanismus. Mozilla folgte diesem Beispiel und stellte einen OneCRL-Block für Firefox-Installationen bis 22:59 UTC desselben Tages bereit. Diese Mechanismen ermöglichen es Browsern, das Vertrauen in bestimmte Zertifikate zu widerrufen, ohne dass ein vollständiges Software-Update oder ein Neustart erforderlich ist. Apple blockierte die Zertifikate am 19. Oktober, Microsoft folgte am 20. Oktober.

Entscheidend ist, dass vor der Implementierung der Chrome-Sperre keine TLS-Zertifikate, die auf die sechs betroffenen Web-Intermediates verweisen, in Certificate Transparency Logs protokolliert worden waren. Dies deutet darauf hin, dass zwar die Schlüssel kompromittiert wurden, sie aber möglicherweise nicht verwendet wurden, um betrügerische Zertifikate auszustellen, die öffentlich sichtbar waren und standardmäßig von Chrome vertraut wurden. Es bleibt jedoch unbekannt, wie die Schlüssel exfiltriert wurden, wann der Einbruch stattfand oder ob andere Akteure neben dem meldenden Forscher im Besitz der Schlüssel sind. Auch die Programmiersprache Go veröffentlichte am 20. Oktober dringende Sicherheitsupdates, um Ketten abzulehnen, die diese Schlüssel enthalten, und behandelte das Problem aufgrund der potenziellen Bedrohung für die Integrität des Ökosystems mit maximaler Schweregrad-Einstufung.

Wichtige Details

• Acht private Schlüssel der Intermediate-CA von eMudhra wurden kompromittiert, was sowohl TLS- als auch Code-Signing-Zertifikate betrifft.
• Chrome und Firefox blockierten die Zertifikate innerhalb weniger Stunden nach der Meldung am 17. Oktober, jeweils über CRLSet und OneCRL.
• In den Certificate Transparency Logs wurden vor der Sperre keine betrügerischen TLS-Zertifikate gefunden, die auf die betroffenen Intermediates verweisen.
• Go veröffentlichte am 20. Oktober die Versionen 1.27.3 und 1.26.10, um diese Schlüssel hart abzulehnen, was Entwickler zwingt, ihre Anwendungen neu zu kompilieren.
• Mozilla entfernte die emSign ECC Root CA - G3 aus seinem NSS-Trust-Store, was zu Verbindungsproblemen bei Servern führen kann, die weiterhin diese Wurzel verwenden.
• Das certifi-Bundle von Python und webpki-roots von Rust wurden aktualisiert, um die betroffene Wurzel zu entfernen, was Paket-Updates für Backend-Dienste erfordert.

Hintergrund

Um die Schwere des Vorfalls zu verstehen, muss man zwischen Root- und Intermediate-Zertifikaten unterscheiden. Ein Root-Zertifikat ist der ultimative Vertrauensanker in einem Browser oder Betriebssystem. Intermediate-Zertifikate fungieren als Brücken; sie werden von der Root signiert und signieren wiederum die tatsächlichen Zertifikate, die von Websites verwendet werden. Diese Hierarchie ermöglicht es CAs, ihre hochsensiblen Root-Schlüssel offline und sicher zu halten. Wenn ein Intermediate-Schlüssel kompromittiert wird, wie in diesem Fall, lässt sich der Schaden leichter eingrenzen als bei einer Root-Kompromittierung, aber Angreifer können dennoch jede Website impersonalisieren, der dieses Intermediate vertraut.

Certificate Transparency (CT) ist ein öffentliches Ledger-System, das alle ausgestellten TLS-Zertifikate aufzeichnet. Es dient als Audit-Trail und ermöglicht es Domain-Inhabern und Browsern, falsch ausgestellte Zertifikate zu erkennen. Die Tatsache, dass vor der Sperre keine CT-Logs für die kompromittierten eMudhra-Intermediates existierten, ist ein positives Zeichen, das darauf hindeutet, dass ein großflächiger Missbrauch verhindert wurde oder von der öffentlichen Überwachung nicht erkannt wurde. Viele Backend-Systeme und ältere Clients erzwingen jedoch keine strikte CT-Protokollierung oder prüfen keine Widerruflisten wie CRLSet, was sie verwundbar macht, bis ihre Trust-Stores explizit aktualisiert werden.

Warum es wichtig ist

Für Teams, die Self-Hosted-Software betreiben, unterstreicht dieser Vorfall die Fragilität des impliziten Vertrauens in Drittanbieter-Zertifizierungsstellen. Während Webbrowser automatische Widerrufs-Updates erhalten, verlassen sich viele serverseitige Anwendungen, interne Tools und Microservices auf statische Trust-Bundles oder systemweite Zertifikatspeicher, die sich nicht automatisch aktualisieren. Beispielsweise werden Python-Anwendungen, die das certifi-Bundle verwenden, oder Go-Binaries, die mit älteren Versionen kompiliert wurden, weiterhin den kompromittierten Schlüsseln vertrauen, bis die zugrunde liegenden Bibliotheken aktualisiert und die Anwendung erneut bereitgestellt wird. Dies schafft ein Zeitfenster der Verwundbarkeit für interne APIs und Service-zu-Service-Kommunikation, die auf TLS-Mutual-Authentication angewiesen sind.

Darüber hinaus bedeutet die Entfernung der emSign ECC Root CA - G3 aus Trust-Stores wie Mozillas NSS und Pythons certifi, dass alle legitimen Dienste, die noch Zertifikate verwenden, die auf diese Root verweisen, plötzlich unerreichbar werden. Dies ist nicht nur eine Sicherheitskorrektur, sondern ein potenzieller Verfügbarkeitsvorfall. DevOps-Ingenieure müssen überprüfen, ob externe Abhängigkeiten oder Partnerintegrationen eMudhra-Zertifikate verwenden. Falls ja, werden diese Verbindungen fehlschlagen, bis die Gegenpartei ihre Zertifikate unter einer anderen, vertrauenswürdigen Root neu ausstellt. Dies unterstreicht die Notwendigkeit eines aktiven Monitorings der Zertifikatsgültigkeit und Issuer-Änderungen, anstatt sich auf eine „einmal einstellen und vergessen“-Zuverlässigkeit zu verlassen.

Was Sie tun können

• Aktualisieren Sie alle Go-Installationen sofort auf Version 1.27.3 oder 1.26.10 und bauen Sie betroffene Binaries neu, um sicherzustellen, dass die neue Ablehnungslogik aktiv ist.
• Prüfen Sie Ihre Python-Umgebungen und aktualisieren Sie das certifi-Paket auf Version 2026.10.19 oder höher, um die nicht vertrauenswürdige Root aus Ihrem Bundle zu entfernen.
• Auditten Sie Ihre Server-Logs auf Verbindungen zu Diensten, die eMudhra-Zertifikate verwenden, da diese nun aufgrund der Root-Entfernung in aktualisierten Trust-Stores fehlschlagen könnten.
• Stellen Sie sicher, dass Ihre internen Monitoring-Systeme auf Änderungen des Zertifikats-Issuers prüfen, nicht nur auf Ablaufdaten, um ähnliche Migrationen oder Kompromittierungen frühzeitig zu erkennen.
• Stellen Sie sicher, dass Ihre Firefox-Installationen auf Version 158.0.1, ESR 115.43.1 oder ESR 153.5.1 aktualisiert sind, falls sie Remote Settings-Updates nicht automatisch empfangen können.
• Überprüfen Sie Ihr Dependency Management für Rust- und Node.js-Projekte und achten Sie auf ausstehende Updates für webpki-roots und Node.js selbst, die diese Kompromittierung beheben.