Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Bezpieczeństwo portfeli kryptowalutowych zależy nie tylko od algorytmów kryptograficznych, ale także od jakości losowości wykorzystywanej podczas generowania fraz odzyskiwania. Jeżeli źródło entropii jest przewidywalne, nawet poprawnie zaimplementowane mechanizmy ochrony mogą zostać podważone. Właśnie taki scenariusz dotyczy podatności określanej jako Ill Bloom, powiązanej z funkcją CryptoJS.lib.WordArray.random().
Problem polega na tym, że część aplikacji używała tej funkcji do tworzenia materiału wejściowego dla fraz seed BIP39. W efekcie tajne dane, które powinny być praktycznie niemożliwe do odgadnięcia, mogły zostać zredukowane do przestrzeni możliwej do przeszukania przez atakujących.
W skrócie
Badacze bezpieczeństwa powiązali serię kradzieży środków z portfeli kryptowalutowych ze słabym generatorem pseudolosowym w bibliotece CryptoJS. Według opublikowanych analiz skutki dwóch fal ataków miały doprowadzić do strat sięgających co najmniej 5,69 mln dolarów.
- podatność obniżała efektywną entropię fraz odzyskiwania,
- atakujący mogli odtwarzać możliwe seedy i wyprowadzać z nich adresy portfeli,
- problem dotyczył wybranych aplikacji wykorzystujących wadliwą funkcję do celów bezpieczeństwa,
- sama aktualizacja aplikacji nie naprawia fraz seed wygenerowanych wcześniej.
Kontekst / historia
Źródła problemu sięgają starszych wersji biblioteki CryptoJS. W 2014 roku wprowadzono własny mechanizm pseudolosowy typu Multiply-With-Carry, inicjalizowany przez Math.random(), co z perspektywy bezpieczeństwa kryptograficznego było rozwiązaniem niewystarczającym.
Choć w wersjach 3.2.0 i 3.2.1 biblioteka korzystała tymczasowo z natywnych źródeł kryptograficznej losowości, zmiana została później cofnięta ze względów kompatybilności. Trwały powrót do bezpieczniejszych mechanizmów nastąpił dopiero w wersji 4.0.0. W 2026 roku badacze połączyli serię incydentów z przewidywalnymi frazami odzyskiwania generowanymi właśnie z użyciem tej wadliwej ścieżki.
W analizach publicznie wskazano pięć aplikacji, które miały zostać dotknięte problemem: RRWallet, Bexo Wallet, NanChat, Bitcoin Libre oraz Milo. Nie we wszystkich przypadkach opublikowano jednak pełny zakres podatnych wersji, a część projektów została już porzucona lub ograniczyła wsparcie.
Analiza techniczna
Kluczowym aspektem podatności jest rozbieżność między deklarowaną a rzeczywistą entropią. Dla standardowych fraz seed opartych na 128-bitowym lub 256-bitowym materiale wejściowym oczekuje się astronomicznie dużej przestrzeni wyszukiwania. W podatnej implementacji efektywna entropia miała jednak spaść odpowiednio do około 2^39 i 2^47, co radykalnie obniżyło próg ataku.
W praktyce atak polegał na odtworzeniu działania wadliwego generatora, wygenerowaniu zbioru potencjalnych wyników PRNG, przekształceniu ich w poprawne frazy BIP39, a następnie wyprowadzeniu kluczy prywatnych i adresów dla różnych łańcuchów bloków. Kolejnym krokiem było porównanie otrzymanych adresów z publicznie dostępnymi danymi on-chain w celu identyfikacji portfeli posiadających środki.
Istotne jest to, że obecność biblioteki crypto-js w projekcie nie oznacza automatycznie podatności. Realne zagrożenie pojawia się dopiero wtedy, gdy wadliwa funkcja zostaje użyta do generowania sekretów o znaczeniu kryptograficznym, takich jak seed, klucz prywatny, token resetujący lub inny wrażliwy identyfikator.
Problem mógł dodatkowo rozprzestrzeniać się przez zależności pośrednie i forki bibliotek, które zastępowały natywne źródła losowości wywołaniami CryptoJS. To klasyczny przykład ryzyka łańcucha dostaw, w którym aplikacja dziedziczy krytyczną słabość mimo braku bezpośredniej implementacji własnej kryptografii.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest trwały charakter kompromitacji. Jeśli fraza odzyskiwania została wygenerowana przy użyciu słabej entropii, późniejsze poprawki biblioteki lub aktualizacje aplikacji nie usuwają problemu. Sam sekret pozostaje przewidywalny, a więc potencjalnie możliwy do odtworzenia przez osoby trzecie.
Ryzyko ma również charakter wielołańcuchowy. Jedna fraza seed może kontrolować środki w kilku sieciach jednocześnie, dlatego skutki naruszenia mogą obejmować więcej niż jeden ekosystem blockchain. W analizach uwzględniano między innymi Bitcoin, Ethereum, Tron, Polygon oraz Rootstock, ale potencjalny wpływ może być szerszy.
Dla twórców aplikacji Web3 to również ważna lekcja procesowa. Naruszenie nie wymagało łamania nowoczesnych algorytmów kryptograficznych, lecz wykorzystania błędu na bardzo wczesnym etapie generowania sekretu. Pokazuje to, jak krytyczne znaczenie ma dobór źródła losowości.
Rekomendacje
Użytkownicy, którzy utworzyli portfel w potencjalnie podatnej aplikacji, powinni założyć, że wygenerowana w ten sposób fraza odzyskiwania jest skompromitowana. Najbezpieczniejszym rozwiązaniem jest utworzenie zupełnie nowego portfela z nową frazą seed wygenerowaną przez zaufane, kryptograficznie bezpieczne źródło oraz szybka migracja środków na nowe adresy.
Samo przeniesienie starej frazy do innej aplikacji lub portfela sprzętowego nie eliminuje zagrożenia. Zmiana interfejsu nie zmienia jakości sekretu, który od początku mógł być przewidywalny.
- nie używać
CryptoJS.lib.WordArray.random()do operacji związanych z bezpieczeństwem, - wymusić stosowanie natywnych kryptograficznych API systemu lub przeglądarki,
- przeprowadzić przegląd zależności pod kątem pośredniego użycia słabego PRNG,
- jasno wskazać użytkownikom zakres podatnych wersji,
- przygotować procedury migracji środków i regeneracji seedów,
- objąć audytem procesy generowania kluczy, seedów i tokenów bezpieczeństwa.
Z perspektywy DevSecOps warto też wdrożyć testy wykrywające użycie niekryptograficznych generatorów liczb losowych w kontekstach wrażliwych. Kontrola powinna obejmować zarówno kod własny, jak i biblioteki zewnętrzne oraz ich pochodne.
Podsumowanie
Incydent Ill Bloom pokazuje, że jakość entropii pozostaje jednym z fundamentów bezpieczeństwa kryptowalut. W tym przypadku słabość w popularnej bibliotece JavaScript miała doprowadzić do generowania przewidywalnych fraz odzyskiwania, a w konsekwencji do przejęć portfeli i strat szacowanych na co najmniej 5,7 mln dolarów.
Najważniejszy wniosek jest prosty: jeśli seed został wygenerowany przez słaby PRNG, sama aktualizacja oprogramowania nie wystarczy. Konieczne jest wygenerowanie nowego sekretu i pełna migracja środków.