CryptoJS i Ill Bloom: słaby RNG po 12 latach kosztował co najmniej 5,7 mln USD

Śledztwo Coinspect połączyło kampanię Ill Bloom z funkcją CryptoJS.lib.WordArray.random(), która przez lata była używana do tworzenia materiału kryptograficznego w aplikacjach JavaScript. Co najmniej pięć portfeli generowało z jej pomocą frazy odzyskiwania o zbyt małej lub przewidywalnej entropii. Analiza dwóch fal transferów oszacowała potwierdzone straty na co najmniej 5,7 mln USD.

To nie było złamanie algorytmu szyfrowania ani blockchaina. Klucze prywatne mogą mieć prawidłową długość i format, a mimo to być słabe, jeśli generator wybiera je z małego, odtwarzalnego zbioru. Atakujący oblicza kandydatów offline, sprawdza odpowiadające im adresy i przenosi środki bez kontaktu z ofiarą.

Gdzie powstała słabość

Historyczne wersje CryptoJS korzystały z mechanizmów losowych środowiska JavaScript, które nie gwarantowały kryptograficznej jakości we wszystkich przeglądarkach i kontenerach aplikacji mobilnych. WordArray.random() wyglądała jak API do generowania losowych bajtów, więc deweloperzy używali jej do seedów i mnemoniców bez dodatkowej walidacji źródła entropii.

Jeżeli przestrzeń wejściowa ma mniej bitów nieprzewidywalności niż deklaruje wynik, rozciągnięcie hashem nie dodaje nowych informacji. Długi seed może być tylko deterministycznym obrazem krótkiego stanu PRNG. Dla napastnika liczy się liczba możliwych stanów i możliwość odtworzenia czasu, platformy lub kolejności wywołań.

Materiały projektu Ill Bloom łączą analizę kodu aplikacji, reverse engineering wycofanych wersji i śledzenie transakcji w kilku sieciach. Coinspect identyfikował rodziny adresów wynikające ze słabych fraz, a następnie obserwował skoordynowane sweeps. To mocniejszy dowód niż sama obecność starej biblioteki: pokazuje zgodność przyczyny technicznej z ruchem środków.

Kto powinien reagować

Ryzyko dotyczy portfeli, które wygenerowały nową frazę przy użyciu podatnego kodu. Aktualizacja aplikacji nie wzmacnia istniejącego seeda. Import starej frazy do nowej, bezpiecznej wersji także pozostawia środki pod kluczem wyprowadzonym z tej samej słabej entropii.

Użytkownik potrzebuje nowego portfela i nowej frazy utworzonej przez zweryfikowany CSPRNG, a następnie transakcji przenoszącej aktywa. Operację należy wykonać z czystego urządzenia i uważać na fałszywe „narzędzia naprawcze”, które proszą o wpisanie mnemonika.

Plan dla producentów i użytkowników

1. Zidentyfikuj wszystkie wersje aplikacji i momenty, w których generowały one klucze, nonce, tokeny lub frazy odzyskiwania.
2. Zastąp ogólny RNG systemowym CSPRNG, np. Web Crypto crypto.getRandomValues(), i przerwij operację, jeśli nie jest dostępny.
3. Dodaj testy, które wykrywają fallback do Math.random(), powtarzalność po restarcie i zbyt małą różnorodność wyników.
4. Powiadom użytkowników językiem wyjaśniającym konieczność utworzenia nowej frazy, nie tylko aktualizacji aplikacji.
5. Nie buduj internetowego „skanera” wymagającego seeda; weryfikacja powinna używać publicznych adresów lub działać offline.
6. Monitoruj on-chain znane wzorce i przygotuj bezpieczną, priorytetową ścieżkę migracji środków.
7. Traktuj generator losowy i jego środowisko uruchomieniowe jako element audytu kryptograficznego i łańcucha dostaw.

Jak prowadzić analizę po utracie środków

Zespół incident response powinien zabezpieczyć nie tylko adres i historię transakcji, lecz również wersję aplikacji, lockfile, bundle JavaScript, sposób generowania portfela, zegar urządzenia i źródła entropii dostępne w danym runtime. To pozwala odróżnić kradzież klucza po jego utworzeniu od przewidywalnego klucza od początku. Ponowna instalacja aplikacji przed zachowaniem artefaktów może usunąć najważniejszy dowód.

Deweloperzy powinni mieć test, który w kontrolowanym środowisku przerywa build, gdy bezpieczny CSPRNG nie jest dostępny — generator nie może cicho przechodzić na słabszą funkcję. SBOM powinien zapisywać także bundlowaną wersję biblioteki, bo numer w package.json nie zawsze odpowiada kodowi dostarczonemu użytkownikowi. Dla nowych portfeli warto rozdzielić generowanie klucza od UI i wykonywać je w małym, audytowalnym komponencie wykorzystującym systemowy interfejs kryptograficzny.

Fakty a wnioski

Coinspect potwierdza powiązanie kodu, pięciu aplikacji i transakcji oraz podaje dolne oszacowanie strat. Nie oznacza to, że każdy projekt importujący CryptoJS generował słabe klucze. Znaczenie ma konkretna funkcja, wersja i środowisko.

Wniosek Breachroad: aktualizacja naprawia generator na przyszłość, ale nie naprawia wcześniej utworzonych sekretów. Szkolenia dla deweloperów i testy aplikacji webowych oraz API powinny obejmować pochodzenie entropii i bezpieczną migrację danych kryptograficznych.