Zum Inhalt springen
Beveiligingsnieuws

CryptoJS schwacher RNG: 5,7 Millionen Abfluss

CryptoJS zwakke RNG

Eine neue Untersuchung der Blockchain-Sicherheitsfirma Coinspect bringt Licht in einen besonders teuren Schwachstellenfall: CryptoJS schwacher RNG (ein unzureichender Zufallszahlengenerator) stand demnach hinter Abflüssen von rund 5,7 Millionen US-Dollar bei mehreren Krypto-Wallet-Apps. Betroffen waren Wallets, die den Generator als Quelle für die Entropie nutzten, um Recovery-Phrasen zu erzeugen.

Wichtig: Selbst wenn Nutzer anschließend ein Update einspielen, kann das die bereits erzeugte Recovery-Phrase nicht „reparieren“. Denn die fehlende Zufallsqualität steckt in der Phrase selbst – und bleibt damit langfristig angreifbar.

Was steckt hinter dem CryptoJS schwachen RNG?

Coinspect identifizierte CryptoJS.lib.WordArray.random() als problematische Komponente. Die Funktion wurde in der JavaScript-Kryptobibliothek bereits vor etwa 12 Jahren eingeführt und liefert demnach in den betroffenen Fällen nur schwache Entropie. Diese Entropie floss in die Erstellung von Recovery-Phrasen ein, die Nutzer anschließend verwenden, um Wallet-Funds wiederherzustellen oder zu importieren.

In einem korrekten Szenario würden die verwendeten Entropielängen typischerweise große Suchräume erzeugen. Coinspect erklärt jedoch, dass der Generator die reale Schwierigkeit stark reduziert: Statt geschätzt 2128 bzw. 2256 wurden die Suchräume in der Schwachstellenkette auf ungefähr 239 und 247 verkleinert. Das ist für Angreifer gerade auf üblichen Rechnern prinzipiell enumerierbar.

Welche Wallet-Apps waren betroffen?

Coinspect bestätigt insgesamt fünf Anwendungen, die den Generator als Entropiequelle für die Wiederherstellungsphrase nutzten. Je nach App gab es unterschiedliche Statusmeldungen – von „discontinued“ (eingestellt) bis „repariert“, wobei selbst bei Fixes die bereits erzeugten Phrasen weiterhin kritisch sein können.

  • RRWallet: laut Coinspect eingestellt; kein Fix.
  • Bexo Wallet: laut Coinspect in Version 20.1.0 gefixt. Die aktualisierten Builds seien jedoch zum Zeitpunkt der Prüfung noch nicht hochgeladen gewesen.
  • NanChat: Coinspect zufolge unabhängig bestätigt; betroffen waren Versionen vor 1.3.0. Fix in 1.3.0.
  • Bitcoin Libre: Fix in Version 4, erschienen im Juli 2024.
  • Milo: laut Coinspect eingestellt; kein Fix.

Coinspect erläutert außerdem, dass es im Zuge einer früheren Berichterstattung bereits auf genau diese fünf Wallets verwiesen hatte, damals jedoch ohne namentliche Nennung.

Warum ein Update die Recovery-Phrase nicht „rettet“

Ein zentraler Punkt der Analyse lautet: Wenn eine Recovery-Phrase bereits aus den Ausgaben des schwachen Generators generiert wurde, bleibt sie erratbar. Das gilt nicht nur in der ursprünglichen Wallet-App, sondern auch dann, wenn Nutzer die Phrase später importieren – selbst in eine Hardware Wallet.

Auch weitere kryptografische Schritte, die nach der Generierung auf die Phrase angewendet werden (etwa Hashing oder PBKDF2), können den ursprünglichen Entropiemangel nicht wiederherstellen. Ebenso bringt ein Update allein keine Korrektur für vorhandene Phrasen.

Coinspect empfiehlt daher: Betroffene Nutzer sollten eine neue Recovery-Phrase sicher erzeugen und anschließend die Mittel in die neue Wallet-Struktur übertragen.

Wie Coinspect den Angriff nachstellte

Coinspect beschreibt eine nachvollziehbare Angriffskette, die sich aus öffentlichen Daten speisen konnte. Die Vorgehensweise bestand demnach aus mehreren Schritten: Zuerst wurden mögliche Ausgaben enumeriert, dann in BIP39-Phrasen umgerechnet, daraus wiederum Adressen abgeleitet und diese Adressen anschließend mit Daten aus der öffentlichen Blockchain abgeglichen.

Entscheidend ist hierbei: Wenn die Entropie im Generierungsprozess stark reduziert ist, lassen sich viele Kandidaten systematisch durchprobieren – und die Treffer verraten, welche Wallet-Phrasen mit den Daten übereinstimmen.

Die Zahlen: Abflüsse in zwei Wellen

Coinspect berichtet von zwei Abflusswellen. Eine erste Übertragung am 27. Mai habe etwa 3,14 Millionen US-Dollar von 431 Konten eingesammelt. Die zweite Runde habe zwischen 30. Mai und 13. Juli stattgefunden und laut Analyse etwa 2,55 Millionen US-Dollar betroffen. Dabei standen Adressen im Zusammenhang mit 522 Seeds, darunter rund 2,18 Millionen USDT aus einem Tron-Account am 4. Juli.

In der späteren Auswertung führte Coinspect Tracking für insgesamt 2.114 identifizierte Seeds und die dazugehörigen Adressen durch, verteilt über Bitcoin, Ethereum, Tron, Rootstock und Polygon. Insgesamt ergibt sich dadurch ein gemessener Verlust von 5.690.922 US-Dollar bis zum 13. Juli – Coinspect beschreibt diesen Wert als untere Grenze.

Die Firma schätzt zudem, dass die betroffene Population je nach Netzwerk (insbesondere EVM-kompatible Umgebungen sowie Bitcoin) in die Tausende reicht, nennt jedoch keine wallet-spezifische Aufschlüsselung.

Historie der Schwachstelle in der Bibliothek

Coinspect ordnet die Schwachstelle auch zeitlich ein: Die betroffene Generierung basiert auf einem „Multiply-With-Carry“-Ansatz, der wiederum mit Math.random() geimpft wird. Laut Analyse tauchte diese Logik im Umfeld von Juni 2014 auf.

Es gab dabei allerdings auch Änderungen: Releases 3.2.0 und 3.2.1 stellten demnach auf native kryptografische Zufallsquellen um. Anschließend sei in 3.3.0 der schwache Code jedoch wieder zurückgekehrt, weil die Änderung als „breaking“ eingestuft wurde. Das bedeutet: Ein Upgrade innerhalb der 3.x-Reihe konnte Projekte sowohl von einem Fix zurück in einen verwundbaren Zustand bringen.

Erst mit 4.0.0 wurde die native Zufallslogik dauerhaft wiederhergestellt – laut Coinspect seit Februar 2020.

Warum der Bereich in Advisorys breiter sein kann als die echten Exploit-Fälle

Coinspect weist darauf hin, dass eine Bibliotheksabhängigkeit allein nicht automatisch bedeutet, dass eine Wallet-App tatsächlich angreifbar war. Relevant ist, ob die Anwendung die konkret verwundbare Funktion als Quelle für sicherheitskritische Werte verwendet hat – etwa für die Entropie bei Recovery-Phrasen.

So nennt Coinspect auch eine Sicherheitsmitteilung des CryptoJS-Maintainers mit „Critical“-Bewertung und einem CVSS-Score von 9.0. In deren Paketbeschreibung werden demnach zwar alle Releases unter 4.0.0 als betroffen aufgeführt, während die früher erwähnten Ausnahmen (3.2.0 und 3.2.1) im Text nicht sauber abgebildet sein sollen.

Für Nutzer heißt das: Der Blick auf die tatsächliche Nutzung in der Wallet-Logik ist entscheidend – nicht nur darauf, welche Version eines Pakets installiert ist.

Was Nutzer jetzt tun sollten

Coinspect rät aktiven Wallet-Nutzern, die offiziellen Kanäle der jeweiligen Projekte zu prüfen, insbesondere zu Versionierung und Migrationsanleitungen. Für manche Apps gilt zusätzlich: Wenn eine Wallet eingestellt wurde, gibt es unter Umständen keinen offiziellen Fix, sodass das Generieren einer neuen sicheren Recovery-Phrase der wichtigste Schritt bleibt.

In Bezug auf NanChat wird berichtet, dass der Hersteller mit Version 1.3.0 ein Tool bereitgestellt habe, mit dem Nutzer eine neue Seed-Struktur erzeugen und die Funds umziehen können. Coinspect beschreibt außerdem, dass der CEO und Gründer Juliano Rizzo den Fehler am 10. Juni gemeldet habe und der Fix nur zwei Tage später ausgeliefert worden sei.

Darüber hinaus ist ein technischer Hinweis relevant: Coinspects öffentlicher Prüfer akzeptiert laut Bericht Wallet-Adressen. Ein Treffer bedeutet, dass Assets, die zur gleichen Phrase gehören, möglicherweise unmittelbar gefährdet sind. Ein negatives Ergebnis heißt dagegen nicht zwingend, dass keine Risikoquellen existieren, sondern nur, dass die Adresse nicht in den aktuell veröffentlichten Datensätzen auftaucht.

Fazit: CryptoJS schwacher RNG bleibt eine ernste Gefahr

Der Fall zeigt eindrücklich, wie gefährlich schwache oder falsch eingesetzte Zufallsquellen in Krypto-Ökosystemen sein können. Der CryptoJS schwacher RNG wurde in mehreren Wallet-Apps als Entropiequelle verwendet und ermöglichte laut Coinspect eine systematische Rekonstruktion von Recovery-Phrasen – wodurch Abflüsse in Höhe von rund 5,7 Millionen US-Dollar entstanden.

Updates sind zwar für zukünftige Generationen wichtig, aber sie machen bereits erzeugte Phrasen nicht sicher. Wer eine Recovery-Phrase aus einer betroffenen Generierungspfad erhalten hat, sollte deshalb aktiv handeln: neue Phrase erzeugen und die Gelder anschließend umziehen.

Quelle: https://thehackernews.com/2026/08/cryptojs-weak-rng-behind-57-million-in.html