De kern
Coinspect koppelt de Ill Bloom-diefstallen aan CryptoJS.lib.WordArray.random(), een niet-cryptografisch veilige generator die in walletsoftware werd gebruikt voor herstelzinnen. De kwetsbaarheid staat geregistreerd als CVE-2026-71851.
Lengte is niet hetzelfde als onvoorspelbaarheid
Een herstelzin kan eruitzien alsof zij uit een enorme hoeveelheid mogelijkheden komt. Wanneer de onderliggende generator maar een klein en voorspelbaar deel daarvan gebruikt, kan een aanvaller die kandidaten systematisch nalopen en bijbehorende openbare adressen vergelijken.
Een oude afhankelijkheid reisde mee
De zwakke functie bestond al jaren en bereikte via bibliotheken en forks meerdere toepassingen. Alleen CryptoJS in een project hebben is niet automatisch kwetsbaar; het wordt gevaarlijk wanneer de functie werkelijk wordt gebruikt om sleutels, seeds of andere geheimen te genereren.
Achteraf hashen helpt niet
Extra verwerking met hashing of een sleutelafleidingsfunctie kan ontbrekende entropie niet terugbrengen. Ook het importeren van dezelfde herstelzin in een nieuwe hardwarewallet verandert de oorsprong van het geheim niet.
What does this mean for you?
Een herstelzin kan twaalf of vierentwintig willekeurige woorden bevatten en toch zwak zijn. De veiligheid hangt af van hoeveel echte onvoorspelbaarheid bij het maken aanwezig was. In getroffen walletapps kwamen de woorden uit een veel kleinere verzameling mogelijkheden dan de gebruiker mocht verwachten.
Als jouw herstelzin met een getroffen appversie is gemaakt, helpt alleen bijwerken niet. De oude woorden blijven hetzelfde. De veilige route is een volledig nieuwe herstelzin maken in een vertrouwde, bijgewerkte omgeving en de bezittingen naar de nieuwe adressen verplaatsen.
Kort gezegd: Een update repareert geen herstelzin die eerder met zwakke randomness is gemaakt. Gebruikers van een getroffen versie moeten in een veilige, bijgewerkte omgeving een volledig nieuwe seed genereren en hun bezit verplaatsen.
Wat betekent dit voor je digitale voetafdruk?
Een blockchainadres en alle transacties blijven publiek zichtbaar. Zodra een aanvaller de privésleutel uit een zwakke seed afleidt, kan die niet alleen huidige middelen verplaatsen maar ook toekomstige stortingen volgen en stelen. Het adres kan bovendien gekoppeld raken aan beurzen, diensten en identiteitscontroles.
Voer daarom nooit een herstelzin in een online controletool in. Een betrouwbare controle heeft hoogstens een openbaar adres nodig. Je herstelzin, privésleutel of wallet-back-up vormt de kern van je digitale eigendom en moet offline en exclusief onder jouw controle blijven.
Wat kun je nu doen?
- Controleer app en versie. Vergelijk de wallet waarmee de seed oorspronkelijk is gemaakt met de actuele getroffen lijst. De app waarin je hem later importeerde is niet bepalend.
- Maak een volledig nieuw geheim. Genereer op actuele, vertrouwde hardware of software een nieuwe seed. Hergebruik geen woorden, passphrase of afgeleide sleutel.
- Verplaats, importeer niet. Stuur middelen via echte transacties naar adressen van de nieuwe seed. De oude seed importeren in een hardwarewallet maakt hem niet sterker.
- Controleer alle netwerken. Eenzelfde seed kan adressen op meerdere blockchains afleiden. Controleer ook minder gebruikte netwerken en toekomstige ontvangstadressen.
Voor de techneuten
De advisory beschrijft CryptoJS.lib.WordArray.random() in getroffen versies als niet-cryptografisch veilig. Verzoeken die nominaal 128 of 256 bits entropie moesten leveren, konden effectief terugvallen tot zoekruimtes van ongeveer 2^39 en 2^47. Dat maakt offline enumeratie met gewone hardware realistisch.
Downstream forks gebruikten de uitvoer voor BIP39-mnemonics. PBKDF2, hashing en key derivation vergroten daarna wel de rekenlast, maar voegen geen ontbrekende entropie toe. Een aanvaller kan kandidaatmnemonics genereren, adressen afleiden en die zonder interactie met het slachtoffer vergelijken met openbare blockchainstate.
Technisch uitgewerkte oplossing
- Vind werkelijk risicovol gebruik. Zoek naar WordArray.random en indirecte wrappers in broncode, lockfiles en gebundelde JavaScript. Alleen een dependency op crypto-js bewijst nog geen exploiteerbaarheid.
- Vervang door een CSPRNG. Gebruik Web Crypto getRandomValues in browsers of crypto.randomBytes in Node.js. Laat de toepassing hard falen wanneer een veilige bron niet beschikbaar is.
- Traceer gegenereerde secrets. Bepaal welke seeds, API-tokens, nonces of keys in getroffen versies zijn aangemaakt. Maak een rotatieplan op basis van creatiedatum en functie.
- Roteer het resultaat, niet alleen de bibliotheek. Upgrade naar een veilige versie, genereer ieder mogelijk zwak geheim opnieuw en trek het oude geheim in of verplaats middelen.
- Test entropiebronnen en codepaden. Voeg tests toe die de gebruikte randomnessprovider expliciet controleren. Statistische tests alleen zijn onvoldoende; review ook herkomst, seeding en foutgedrag.
De belangrijkste acties
- Controleer of je wallet en versie in de getroffen lijst voorkomen.
- Voer alleen een openbaar walletadres in bij een controletool — nooit je herstelzin of privésleutel.
- Maak bij blootstelling een nieuwe seed in een vertrouwde omgeving en verplaats de middelen.
Wat weten we nog niet?
- Welke verwijderde of niet-geïdentificeerde walletapps dezelfde functie gebruikten.
- Hoeveel zwakke seeds nog fondsen of toekomstige stortingen kunnen ontvangen.
- Of dezelfde generator buiten wallets voor andere langdurige geheimen is gebruikt.
Bronnen
Dit artikel is een onafhankelijke Nederlandstalige duiding van de genoemde bronnen.