Die Kompromittierung von acht Signaturschlüsseln der indischen Zertifizierungsstelle eMudhra hat eine Lücke zwischen dem Schutz durch Browser und der Software offengelegt, die hinter Websites und Trading-Tools läuft. Am einundzwanzigsten Oktober hatten große Browserhersteller die betroffenen Zertifikate gesperrt. Einige Programme außerhalb von Browsern konnten gefälschte Zugangsdaten jedoch weiterhin akzeptieren, weil sie nicht prüfen, ob Zertifikate widerrufen wurden.
Wichtigste Erkenntnisse
- Forscher konnten acht schwache private Schlüssel wiederherstellen, mit denen Zertifikate zur Vortäuschung vertrauenswürdiger Websites signiert werden konnten.
- Browserhersteller sperrten die betroffenen Zertifikate, doch ein Widerruf allein schützt keine Software, die ihn nicht prüft.
- Es waren keine Krypto-Angriffe gemeldet worden; die Besorgnis erstreckt sich auf veraltete Software im gesamten Internet.
Inhaltsverzeichnis
- Wo die eMudhra-Schlüsselkompromittierung weiterhin Angriffsflächen lässt
- Welche Schutzmaßnahmen hatten die Nutzer erreicht?
- Wie schwache Schlüssel die Website-Verifizierung untergruben
- Warum Trading-Software besondere Aufmerksamkeit erfordert
- Fazit
Wo die eMudhra-Schlüsselkompromittierung weiterhin Angriffsflächen lässt
Entscheidend ist der Unterschied zwischen dem Widerruf eines Zertifikats und der Gewährleistung, dass Software ihm nicht mehr vertraut. eMudhra widerrief die betroffenen Zertifikate, doch der Sicherheitsforscher Scott Helme warnte, dass diese Maßnahme für Programme, die den Widerrufsstatus nicht prüfen, keinen Schutz bietet.
Helme sagte, seine Tests hätten ergeben, dass curl, Python, Node, Go und Java ein gefälschtes Zertifikat für die API von Stripe akzeptierten. Das war eine Demonstration der Zertifikatsakzeptanz und kein Beleg dafür, dass Stripe gehackt worden war.
Ein betrügerisches Zertifikat kann es einem Angreifer, der den Netzwerkverkehr abfängt, ermöglichen, einen vertrauenswürdigen Dienst vorzutäuschen und Datenverkehr auszulesen oder zu verändern. Browser-Sperren unterbinden diesen Weg bei geschützten Browsern; sie belegen jedoch nicht, dass jede separate Anwendung oder jedes Backend einen gleichwertigen Schutz erhalten hat.
| Element | Details |
|---|---|
| Mozilla und Chrome | Beide sperrten die betroffenen Zertifikate am siebzehnten Oktober; Mozillas Sperre erfolgte etwa drei Stunden nach dem Hinweis. |
| Apple | Reagierte am neunzehnten Oktober. |
| Microsoft | Reagierte am zwanzigsten Oktober. |
| Zertifikatswiderruf | eMudhra widerrief die betroffenen Zertifikate, doch die Maßnahme hilft nur, wenn die Software den Widerruf prüft. |
| Verfügbare Korrekturen außerhalb von Browsern | Korrekturen waren für Go, das Python-Paket certifi und Rusts webpki-roots verfügbar. |
| Node.js | Am einundzwanzigsten Oktober stand eine Korrektur noch aus. |
Welche Schutzmaßnahmen hatten die Nutzer erreicht?
Die Reaktion begann, nachdem ein Forscher namens Wayne die Browserhersteller am siebzehnten Oktober alarmiert hatte. Er demonstrierte, dass er alle acht kompromittierten Schlüssel kontrollierte, indem er seine Warnung damit digital signierte. Die Verfügbarkeit von Korrekturen bedeutete nicht, dass jede Installation aktualisiert worden war.
Wie schwache Schlüssel die Website-Verifizierung untergruben
Zertifizierungsstellen stellen die Zugangsdaten bereit, mit denen Browser die Identität von Websites überprüfen. Ihre privaten Signaturschlüssel haben daher eine andere Funktion als ein gewöhnliches Website-Passwort: Mit einem kompromittierten Signaturschlüssel lassen sich echt wirkende Zertifikate für andere Websites erstellen.
Helme sagte, er habe alle acht Schlüssel innerhalb von weniger als einer Sekunde aus öffentlichen Zertifikaten wiederhergestellt. Zu den von ihm ermittelten Werten der privaten Schlüssel gehörten 4 und 56, was verdeutliche, wie wenig Widerstand die Schlüssel ihrer Wiederherstellung entgegensetzten. Seinen Angaben zufolge waren sie seit April 2025 offengelegt.
Helmes Auslegung eines Mozilla-Bug-Tickets zufolge machte eMudhra einen Fehler in seinem Skript zur Schlüsseleinrichtung verantwortlich.
Warum Trading-Software besondere Aufmerksamkeit erfordert
Für Krypto-Nutzer beschränkt sich die relevante Angriffsfläche nicht darauf, eine Börse im Browser aufzurufen. Börsen-Bots, Trading-Skripte und Wallet-Backends können auf die betroffene Software außerhalb von Browsern angewiesen sein. Theoretisch könnte ein gefälschtes API-Zertifikat einer Börse einem Angreifer im selben Netzwerk ermöglichen, den Datenverkehr eines Bots abzufangen oder zu verändern.
Es waren keine Krypto-Angriffe gemeldet worden. Mudit Gupta, Chief Technology Officer von Polygon Labs, sagte, die Schwachstelle sei ein allgemeines Problem der Softwaresicherheit und kein spezifisches Krypto-Problem. Besonders bedenklich sei ältere oder nicht gepatchte Software. Nutzer, die Wallets, Trading-Tools und Geräte auf dem neuesten Stand hielten, seien einem geringeren Risiko ausgesetzt, sagte er.
Fazit
Die Reaktion der Browser schloss einen unmittelbaren Weg zur Vortäuschung von Zertifikaten, löste aber das umfassendere Softwareproblem nicht. Die verbleibende Angriffsfläche hängt davon ab, ob einzelne Tools die kompromittierten Zugangsdaten zurückweisen – und nicht bloß davon, ob der Aussteller sie widerrufen hat.
Weitere Nachrichten lesen
Weitere Nachrichten von FinanceVelix
Haftungsausschluss
Dieser Artikel von FinanceVelix dient der allgemeinen Information und stellt keine persönliche Finanz-, Anlage-, Rechts- oder Steuerberatung dar. Marktpreise, Zinssätze und wirtschaftliche Bedingungen können sich ändern; Anlagen sind mit Verlustrisiken verbunden. Die Angaben beruhen auf den zum Zeitpunkt der Veröffentlichung verfügbaren Informationen und können sich ändern. Prüfen Sie wichtige Informationen eigenständig und ziehen Sie bei Bedarf eine qualifizierte Fachkraft hinzu. Die Erwähnung eines Vermögenswerts, eines Unternehmens oder einer Dienstleistung stellt keine Empfehlung dar.
