Cloudflare hat ein Update zur Ausnutzung und Behebung von acht privaten eMudhra-Zwischenschlüsseln veröffentlicht, die aus öffentlichen Zertifikaten rekonstruiert werden konnten. Zu den Schlüsseln gehörten Werte wie 4, 56, 66 und 115. Dadurch war es jedem möglich, die zugehörigen Signaturschlüssel abzuleiten und Zertifikate zu erstellen, die anfällige Clients möglicherweise akzeptiert hätten.
Das Unternehmen erklärt, dass inzwischen alle Cloudflare-Systeme mit hoher Priorität gepatcht wurden. Die kundenseitigen, auf Ursprünge ausgerichteten Proxys, die den Großteil der ausgehenden Verbindungen verarbeiten, wurden innerhalb weniger Stunden nach der Identifizierung des Problems am 19. Oktober 2026 aktualisiert. Anschließend nutzte Cloudflare eine KI-gestützte Überprüfung seines Quellcodes, um weitere Systeme zu finden, die den schwachen Schlüsseln vertrauten, und ordnete die Behebungsarbeiten nach ihrem potenziellen Einfluss zu.
Um möglichen Missbrauch zu überwachen, fügte Cloudflare seinem ausgehenden Pingora-Dienst Protokollierungsfunktionen hinzu. In der Woche nach der Einführung der Protokollierung registrierte das Unternehmen etwa 22.000 versuchte TLS-Handshakes mit Zertifikaten, die mit den betroffenen eMudhra-Schlüsseln signiert waren. Rund zwei Drittel betrafen Testseiten, darunter emudhra.we-have-a-problem.com. Die meisten der übrigen Versuche stammten von Ursprüngen, bei denen offenbar Zertifikate konfiguriert waren, die von der schwachen Zwischenzertifizierungsstelle signiert wurden.
Bei ungefähr 160 Handshakes verwiesen die Subject Alternative Names der Zertifikate auf Domains, die nichts mit der angeforderten Server Name Indication zu tun hatten. Einige waren mit Geräten des Internets der Dinge für Verbraucher verbunden. Cloudflare erklärte, diese Zertifikate schienen erstellt worden zu sein, nachdem die Schwachstelle öffentlich geworden war. Mindestens eines war auf den 20. Oktober um 18:19 UTC datiert, also weniger als eine Stunde nach Veröffentlichung des Berichts von Mozilla.
Das Unternehmen erklärte jedoch, dass die Beweise derzeit nicht darauf hindeuten, dass die Zertifikate zum Abfangen von Cloudflare-Verbindungen verwendet wurden. Die Zertifikate erschienen häufig als eigene Standardzertifikate von Servern, enthielten Namen, die die Hostnamenprüfung nicht bestanden hätten, und wurden in mehreren Fällen von mehreren Cloudflare-Standorten präsentiert. Cloudflare meldete zudem keine indirekten Anzeichen für eine gezielte Abfangkampagne.
Unabhängig davon ermittelte das Unternehmen, wie viele Besucher der kompromittierten Zertifikatskette weiterhin vertrauten. Dazu verwendete es auf einem Teil seiner Challenge-Seiten zwei Testverbindungen: Ein Endpunkt lieferte ein von eMudhra signiertes Zertifikat, während der andere zunächst als Kontrolle mit einem regulär signierten Zertifikat diente. In der folgenden Woche sammelte Cloudflare 50 Millionen Tests, warnte jedoch, dass die Ergebnisse durch Bot-Datenverkehr beeinflusst wurden und nur Clients umfassten, die JavaScript ausführen konnten.
Die Messungen zeigten, dass aktuelle verbreitete Browser größtenteils gepatcht waren, während ältere Browser und eingebettete Browser weiterhin stärker gefährdet waren. Cloudflare schätzte, dass 30 bis 40 Prozent des Android-WebView-Datenverkehrs die betroffene Kette weiterhin akzeptierten. Mehr als die Hälfte der Tests aus mehreren großen Netzwerken akzeptierte sie weiterhin, wobei das Unternehmen darauf hinwies, dass die Zusammensetzung des Datenverkehrs stark von unbestätigten Bots beeinflusst wurde und die Daten eher als Hinweis denn als endgültiger Beleg zu verstehen seien.
Cloudflare forderte Nutzer und Entwickler auf, die relevanten Updates zu installieren, wobei Entwickler, die macOS verwenden, besonders aufmerksam sein sollten. Das Unternehmen verwies Kunden außerdem auf Hinweise zu Produkten wie WARP und Tunnel. Für die Zukunft erklärte Cloudflare, es wolle schnellere Mechanismen zur Aktualisierung von Vertrauensentscheidungen schaffen, darunter eine breitere Nutzung von Systemen, die Sperr- und Certificate-Transparency-Informationen verteilen können, ohne auf statische Truststores angewiesen zu sein.
Quellen: Cloudflare Blog.