Een blockchainbeveiligingsbedrijf heeft een concrete oorzaak blootgelegd achter wallet-diefstallen die samen worden geschat op minstens $5,7 miljoen. Volgens Coinspect ligt de kern van het probleem bij de CryptoJS zwakke RNG, een functie voor “random” die onvoldoende echte willekeur leverde voor het genereren van recovery-phrases.
Het gaat om gevallen waarin recovery-phrases werden opgebouwd met entropie die te voorspelbaar was. Daardoor konden aanvallers de mogelijke waarden enumereren en zich gerichte toegang verschaffen tot adressen die aan dezelfde seed waren gekoppeld. In dit artikel zetten we op een rij wat er precies gebeurde, welke wallet-apps geraakt zijn en waarom een update niet altijd direct helpt.
Wat is er mis met de CryptoJS zwakke RNG?
Coinspect identificeerde CryptoJS.lib.WordArray.random() als de bron van zwakke willekeur. De functie is al ongeveer 12 jaar onderdeel van CryptoJS. In de praktijk leverde ze “zwakke entropie” voor situaties waarin applicaties die willekeur gebruiken als basis voor security-gevoelige waarden.
Het effect was ingrijpend: terwijl sterke 128- of 256-bit entropie typisch leidt tot enorme zoekruimtes (2128 en 2256), rapporteert Coinspect dat de kwetsbare generator de praktische zoekruimte terugbracht naar grofweg 239 tot 247. Daarmee werd het realistisch om op gewone hardware mogelijke outputs af te tasten.
Waarom recovery-phrases kwetsbaar werden
De aanval draait om recovery-phrases: zinnen die wallet-apps gebruiken om een wallet/seed opnieuw te kunnen reconstrueren. Wanneer een app zo’n phrase maakt op basis van de output van de CryptoJS zwakke RNG, ontstaat er een situatie waarin de phrase nog steeds “wiskundig juist” is, maar voldoende herleidbaar om te gokken of te enumereren.
Coinspect beschrijft dat het mis is zodra de recovery-phrase is gegenereerd met de zwakke entropie. Latere bewerkingen zoals hashing of PBKDF2 kunnen de verloren kwaliteit van de entropie niet herstellen. Met andere woorden: een fix in de afhankelijkheid is alleen zinvol wanneer de phrase niet al eerder met de zwakke generator is gemaakt.
Welke wallet-apps zijn volgens Coinspect geraakt?
Coinspect meldt dat de kwetsbaarheid in totaal door vijf toepassingen werd gebruikt als entropiebron bij recovery-phrase generatie. Daarbij speelt ook de status van updates en distributie een rol.
- RRWallet (volgens Coinspect: discontinued) — geen fix.
- Bexo Wallet — volgens Coinspect gefixt in versie 20.1.0, maar Coinspect stelt dat de bijgewerkte builds op het moment van analyse nog niet waren geüpload.
- NanChat — een onafhankelijke bevestiging voor versies voor 1.3.0; fix in 1.3.0.
- Bitcoin Libre — gefixt in versie 4, die volgens Coinspect in juli 2024 is uitgebracht.
- Milo (volgens Coinspect: discontinued) — geen fix.
Het bedrijf zegt dat het deze vijf apps later opnieuw heeft bevestigd, nadat het eerder in juli ook al een set getroffen wallet-types noemde zonder namen. Voor sommige applicaties ontbreekt op de publieke disclosure een volledig overzicht van exacte affected-version ranges.
Updating lost het probleem niet op wanneer je phrase al gemaakt is
Een belangrijk punt uit de analyse: “app updaten” repareert een bestaande phrase niet. Als een recovery-phrase is voortgekomen uit output van de kwetsbare generator, dan blijft die phrase (waar mogelijk geïmporteerd) in feite guessable voor aanvallers.
Coinspect adviseert in dat geval om een nieuwe recovery-phrase veilig te genereren en de tegoeden daarna over te zetten. Opmerkelijk is dat Coinspect ook aangeeft dat seeds die door hardware worden gegenereerd en veel moderne softwarewallets niet zouden zijn geraakt.
Hoe werd de aanval praktisch uitgevoerd?
Coinspect reconstrueerde de aanval door outputs te enumereren, de resultaten om te zetten naar BIP39-phrases en vervolgens adressen af te leiden. Daarna vergeleek de partij die adressen met publieke data op blockchains.
De analyse richtte zich op entropie van 128-bit en 256-bit, waar de verwachte zoekruimte groot zou moeten zijn. Omdat de generator de effectieve variatie verkleinde, werden de waarden alsnog binnen bereik van een succesvolle zoektocht gebracht.
Twee drain-golven: van eind mei tot juli
Coinspect koppelt de diefstallen aan twee sweep-rondes. De eerste vond plaats rond 27 mei, met een geschatte opbrengst van ongeveer $3,14 miljoen uit 431 accounts.
De tweede ronde liep van 30 mei tot 13 juli. In die periode rapporteert Coinspect ongeveer $2,55 miljoen, gekoppeld aan adressen die gerelateerd waren aan 522 seeds. Daarbij wordt ook een specifieke claim genoemd: ongeveer $2,18 miljoen USDT vanuit één Tron-account op 4 juli.
Op basis van verder onderzoek heeft Coinspect door metingen en tracken van 2.114 geïdentificeerde seeds en bijbehorende adressen verliezen vastgesteld tot $5.690.922 door 13 juli. Coinspect beschrijft dit als een lower bound: het kan dus hoger zijn, maar dit is wat de dataset zichtbaar maakt.
Waarom zat dit niet meteen overal “dicht”?
Een deel van het verhaal gaat over de geschiedenis van het fixen van CryptoJS. Volgens Coinspect is een zwakke generator “een keer” vervangen door native cryptografische randomness, maar die wijziging is later teruggedraaid.
De kwetsbare “Multiply-With-Carry”-generator werd in juni 2014 seeded met Math.random(). Releases 3.2.0 en 3.2.1 schakelden over naar native cryptografische randomness. Toen kwam er echter versie 3.3.0, waarin het zwakke codepad weer werd hersteld omdat de wijziging mogelijk als breaking werd gezien. Daardoor kon een project door een upgrade binnen de 3.x-lijn alsnog terugvallen op zwakke willekeur.
Pas met 4.0.0 werd native randomness volgens Coinspect definitief hersteld, in februari 2020.
Hoe kan een afhankelijkheid “aanwezig” zijn zonder direct getroffen te zijn?
In het openbaar advies wordt benadrukt dat een applicatie alleen als getroffen wordt gezien als die de kwetsbare functie ook daadwerkelijk gebruikt om security-sensitive waarden te genereren. Alleen het hebben van de dependency in het pakket betekent dus niet automatisch dat de app exploiteerbaar is.
Dat verklaart ook waarom package-ranges soms breder lijken dan de lijst van echt misbruikbare wallet-applicaties. Het is dus vooral de combinatie van afhankelijkheid én actief gebruik die telt voor het risico.
Wat moeten gebruikers en beheerders nu doen?
Coinspect adviseert gebruikers van wallet-apps die nog in omloop zijn om de officiële kanalen te raadplegen voor de laatste versie en migratie-instructies. Niet elke fix is op het moment van publicatie al beschikbaar geweest via appstores, zoals bij Bexo werd opgemerkt.
Voor apps waarbij Coinspect expliciet stelt dat oudere versies kwetsbaar zijn, geldt: als je phrase vermoedelijk via de CryptoJS zwakke RNG is gegenereerd, maak dan een nieuwe seed/recovery-phrase en verplaats je fondsen. Dat is de enige manier om de exposure te stoppen, omdat een bestaande phrase niet “retroactief” beter wordt.
Extra aandacht: supply chain en crypto-afhankelijkheden
Deze casus is een klassiek voorbeeld van hoe problemen in een cryptografische library doorwerken naar eindproducten. In dit soort supply chain scenario’s kan één kwetsbare helperfunctie in een gedeelde module uiteindelijk de zwakste schakel vormen — zelfs wanneer de rest van de wallet-app correct lijkt.
Als je meer wilt lezen over het bredere verschil tussen beleid, controle en wat je in de praktijk moet borgen binnen cyberrisk en compliance, dan kan dit artikel je helpen: Bron: https://thehackernews.com/2026/08/cryptojs-weak-rng-behind-57-million-in.html
