Schwache Schlüssel bei eMudhra ermöglichen sofortige Zertifikatsfälschung und verzögerte Patches

Am 19. Oktober 2026 identifizierte Cloudflare ein schwerwiegendes Sicherheitsversagen im Zusammenhang mit eMudhra, einer Zertifizierungsstelle, die acht Zwischen-Private-Schlüssel mit vernachlässigbarer Entropie generiert hatte. Anstatt komplexe, unvorhersehbare Zahlen zu verwenden, nutzte eMudhra einfache Ganzzahlen wie 4, 56 und 237, was es jedem ermöglichte, die Private Keys aus öffentlichen Zertifikaten zu rekonstruieren. Diese beispiellose Schwachstelle erlaubt es Angreifern, gültige TLS-Zertifikate für jede Domain zu fälschen und so die Standard-Verschlüsselungsschutzmaßnahmen für nicht gepatchte Clients zu umgehen.

Was passiert ist

Das Kernproblem liegt in einem katastrophalen Fehler im Schlüsselgenerierungsprozess von eMudhra. Eine Zertifizierungsstelle (CA) wird vertraut, eine massive Zufallszahl als Grundlage ihrer kryptografischen Sicherheit auszuwählen. In diesem Fall wählte eMudhra ein- oder zweistellige Zahlen. Da diese Werte so klein sind, kann ein Angreifer den privaten Signaturschlüssel nahezu augenblicklich unter Verwendung nur des öffentlichen Zertifikats wiederherstellen. Dies unterscheidet sich grundlegend von früheren CA-Verletzungen, wie bei DigiNotar oder TrustWave, wo gestohlene Schlüssel geschützte Assets waren, die nur bestimmten Bedrohungsakteuren zugänglich waren. Hier sind die Schlüssel mathematisch trivial ableitbar für jeden mit einfachen Werkzeugen.

Cloudflare reagierte sofort, indem es seine Hochauswirkungssysteme, einschließlich Pingora-Proxies, innerhalb weniger Stunden nach der Entdeckung patchte. Das Unternehmen setzte KI-gestützte Code-Analyse ein, um alle internen Systeme zu identifizieren, die diesen schwachen Schlüsseln vertrauten, und vergab Remediation-Tickets basierend auf dem Risikolevel. Zur Überwachung der realen Ausnutzung fügte Cloudflare Logging hinzu, um Handshakes zu erkennen, die die kompromittierten Schlüssel involvierten. Innerhalb einer Woche wurden etwa 22.000 versuchte Handshakes aufgezeichnet. Während die meisten harmlose Tests oder selbstsignierte Konfigurationen waren, betrafen etwa 160 Versuche gefälschte Zertifikate, die unrelated Domains benannten, darunter Consumer-IoT-Geräte. Diese Fälschungen traten bereits Stunden nach der öffentlichen Bekanntmachung der Schwachstelle auf, obwohl keine erfolgreiche Abfangung von Cloudflare-Traffic festgestellt wurde.

Um die globale Verwundbarkeit zu bewerten, stellte Cloudflare Probe-Verbindungen über ihre Challenge-Seiten bereit, um zu testen, ob Browser der Besucher Zertifikate akzeptierten, die mit den schwachen Schlüsseln signiert waren. Die Daten zeigen eine beunruhigende Verzögerung bei der Adoption von Patches. Während moderne Desktop-Browser größtenteils aktualisiert wurden, akzeptieren eingebettete Systeme wie Android WebView immer noch die kompromittierten Ketten mit Raten von 30–40 %. Darüber hinaus vertrauen mehr als die Hälfte der Proben über große Netzwerke hinweg weiterhin den ungültigen Zertifikaten, was darauf hindeutet, dass ein erheblicher Teil des Internets potenziellen Man-in-the-Middle-Angriffen ausgesetzt bleibt.

Wichtige Details

• eMudhra verwendete extrem schwache Ganzzahlen (4, 56, 66, 115, 155, 156, 230, 237) für acht Zwischen-Private-Schlüssel.
• Private Keys können augenblicklich aus öffentlichen Zertifikaten wiederhergestellt werden, was uneingeschränkte Zertifikatsfälschung ermöglicht.
• Cloudflare beobachtete innerhalb einer Woche nach der Offenlegung rund 22.000 Handshake-Versuche unter Verwendung der schwachen Schlüssel.
• Gefälschte Zertifikate wurden bereits am 20. Oktober erstellt, weniger als eine Stunde nachdem Mozilla den Bug-Report veröffentlichte.
• Über 50 Millionen Proben deuten darauf hin, dass viele eingebettete Browser und Bots der kompromittierten Zertifikatskette weiterhin vertrauen.
• eMudhra hat seinen Rückzug aus dem öffentlichen CA-Geschäft angekündigt, aber das fehlerhafte Schlüsselgenerierungsskript nicht freigegeben.

Hintergrund

Zertifizierungsstellen (CAs) sind vertrauenswürdige Dritte, die digitale Zertifikate ausstellen, um die Identität von Websites zu verifizieren. Diese Zertifikate basieren auf Public-Key-Kryptografie, bei der ein privater Schlüssel Daten signiert und ein öffentlicher Schlüssel sie verifiziert. Die Sicherheit dieses Systems hängt vollständig davon ab, dass der private Schlüssel geheim bleibt und mit hoher Entropie generiert wird, was bedeutet, dass er aus einem riesigen Pool möglicher Zahlen gewählt wird. Wenn die Zahl vorhersagbar oder klein ist, wird die mathematische Beziehung zwischen öffentlichem und privatem Schlüssel leicht umkehrbar.

In diesem Vorfall bedeutete der Mangel an Entropie, dass das „Schloss“, das das Vertrauensmodell des Internets schützt, effektiv offen gelassen wurde. Jeder Akteur konnte ein gültiges Zertifikat für eine Ziel-Domain generieren, wie z. B. eine Bankseite oder ein internes Unternehmensportal. Clients, die Certificate Transparency nicht durchsetzen oder Revocation-Listen nicht prüfen, akzeptieren diese gefälschten Zertifikate als legitim, wodurch Angreifer Traffic entschlüsseln und modifizieren können, ohne Browser-Warnungen auszulösen.

Warum es wichtig ist

Für Teams, die Self-Hosted-Infrastruktur oder interne Services verwalten, hebt dieser Vorfall die Fragilität des impliziten Vertrauens in externe CAs hervor. Selbst wenn Ihre Organisation eMudhra nicht direkt nutzt, könnten die Geräte Ihrer Mitarbeiter, Mobile Apps und IoT-Endpunkte weiterhin der kompromittierten Root- oder Zwischenzertifikaten vertrauen. Wenn ein Angreifer ein Zertifikat für Ihre interne Domain fälscht, könnten ungepatchte Clients sich mit einem böswilligen Server verbinden und glauben, es sei Ihr legitimer Service. Dieses Risiko ist besonders akut für Legacy-Systeme, eingebettete Geräte und automatisierte Bots, die keine regelmäßigen Sicherheitsupdates erhalten.

Die langsame Patch-Rate bei eingebetteten Browsern und netzwerkseitigen Clients deutet darauf hin, dass Schwachstellen in der Lieferkette lange nach der Offenlegung bestehen bleiben. IT-Leiter müssen davon ausgehen, dass ein Teil ihrer Nutzerschaft weiterhin anfällig für Zertifikatsspoofing ist. Sich ausschließlich auf Browser-Updates zu verlassen, ist unzureichend; Organisationen benötigen aktives Monitoring, um anomale Zertifikatsnutzung zu erkennen und sicherzustellen, dass ihre eigenen Dienste schwache oder widerrufene Credentials explizit ablehnen. Dieses Ereignis unterstreicht die Notwendigkeit dynamischer Trust Stores, die schlechte Akteure schnell widerrufen können, anstatt sich auf statische Listen zu verlassen, die Monate brauchen, um sich zu verbreiten.

Was Sie tun können

• Aktualisieren Sie alle Betriebssysteme, Browser und eingebettete Software auf die neuesten Versionen, um sicherzustellen, dass schwache Roots nicht mehr vertraut werden.
• Konfigurieren Sie Server so, dass sie strikte Certificate Transparency durchsetzen und Zertifikate von bekannten kompromittierten CAs ablehnen.
• Überwachen Sie Logs auf TLS-Handshakes, die eMudhra-Zwischenschlüssel involvieren, um potenzielle Abfangversuche zu erkennen.
• Prüfen Sie interne Anwendungen und IoT-Geräte, um sicherzustellen, dass sie kein hartcodiertes Vertrauen für die betroffenen eMudhra-Schlüssel enthalten.
• Folgen Sie crowdsourced Remediation-Guides, insbesondere für macOS-Entwickler, die manuelle Anpassungen der Trust Store vornehmen müssen.
• Implementieren Sie automatische Alerts für Zertifikatsänderungen auf kritischen Domains, um unbefugte Issuances schnell zu erkennen.