Luka w firmware Coldcard umożliwiła kradzież 1 367 BTC (ok. 89 mln USD)

Atak na portfele sprzętowe Coldcard ujawnił krytyczną wadę w procesie generowania kluczy prywatnych. W trzech falach napastnicy wykorzystali słabą losowość seedów tworzonych przez podatne wersje firmware i wyprowadzili łącznie ok. 1 367 BTC (ok. 89 mln USD) z tysięcy adresów. Nie był to phishing ani włamanie na giełdę. Celem był sam mechanizm generowania seedów wewnątrz urządzenia: błąd w oprogramowaniu sprzed pięciu lat powodował zbyt małą entropię, co pozwalało odtworzyć klucze prywatne offline i przejąć środki. Co się stało: 89 mln USD w BTC wyprowadzone w trzech falach 30 lipca 2026 r. nieznany sprawca rozpoczął opróżnianie portfeli Coldcard. W pierwszej fali zniknęło 594 BTC (ok. 38 mln USD) z ok. 500 portfeli w zaledwie 25 minut. Atakujący uderzał najpierw w portfele o najwyższej wartości. Druga fala zwiększyła straty do 1 082 BTC (ok. 70 mln USD) z 1 196 adresów w ciągu 41 minut. Do 2 sierpnia, po trzech falach, skumulowane straty wyniosły 1 367 BTC (ok. 89 mln USD) z 4 585 adresów. Z ustaleń Chainalysis wynika, że środki nie były wybierane losowo: operator priorytetyzował najbogatsze cele i zebrał ponad 30 mln USD w pierwszych 10 minutach. Jeden portfel stracił ok. 1,8 mln USD. Taki wzorzec wskazuje na wcześniejsze wytypowanie wartościowych adresów i realizację kradzieży w zaplanowanej kolejności. Szeroki "sweep" trwał niemal 30 godzin, zanim Coinkite opublikowało pierwsze publiczne ostrzeżenie. Galaxy Research zidentyfikowało później ok. 600 podejrzanych adresów atakujących i przekazało je śledczym; firma wskazała też podobieństwa operacyjne między falą 1 i 2, przy innym sposobie zbierania środków w fali 3. Kluczowa różnica: sprawca nie potrzebował dostępu do urządzeń To nie był przypadek kradzieży kluczy z urządzenia ani zdalnego przejęcia portfela. Wrażliwe modele generowały słabe seedy w momencie inicjalizacji. To umożliwiło rekonstrukcję kluczy prywatnych offline. Dla użytkowników to szczególnie dotkliwe, bo Coldcard jest kupowany właśnie po to, by izolować klucze od zagrożeń online. Tymczasem niewystarczająca losowość pochodziła z samego produktu. Oś czasu i źródło błędu 1 marca 2021 r. pojedynczy commit zmienił sposób generowania seedów: zamiast ckcc.rng_bytes (korzystającego ze sprzętowego RNG w chipie STM32) użyto ngu.random.bytes, czyli programowego PRNG opartego o deterministyczne wejścia. 17 marca 2021 r. wydano firmware v4.0.0 z wadliwym kodem. Błąd przetrwał kolejne aktualizacje przez pięć lat, mimo przeglądów bezpieczeństwa i audytu wspieranego przez AI. Według informacji z komunikatów i analiz, seedy tworzone na Mk2 i Mk3 od tego momentu miały ok. 40 bitów entropii. Mk4, Mk5 i Q otrzymywały dodatkowy wkład z secure elementu, co podnosiło efektywną entropię do ok. 72 bitów. Oba poziomy pozostawały jednak poniżej oczekiwanego standardu 128 bitów dla generowania seedów Bitcoina. Jak działała podatność: "jedna linia kodu" i pięć lat ciszy Programowy PRNG korzystał m.in. z numeru seryjnego urządzenia, wartości timera i historii wcześniejszych wywołań RNG, a następnie mieszał te dane przez SHA256d. Hashowanie nie tworzy nowej losowości — jedynie przekształca to, co już istnieje. Jeśli na wejściu jest ograniczona liczba możliwych stanów, tyle samo pozostaje na wyjściu. Dla Mk3 oznaczało to przestrzeń ok. 2^40 możliwości. CEO Foundation Devices Zach Herbert wskazywał, że błąd mógł pojawić się przy dużej przebudowie firmware w marcu 2021 r., związanej z usuwaniem pozostałości kodu GPL i wymianą bibliotek kryptograficznych, a nie w wyniku świadomej decyzji bezpieczeństwa. Niezależnie od intencji, wadliwy mechanizm pozostał aktywny przez pięć lat. Jak doszło do kradzieży: brute force seedów o 40-bitowej entropii Atakujący mógł oszacować kluczowe zmienne (UID urządzenia, stan timera, sekwencję wywołań RNG), a następnie offline odtwarzać możliwe strumienie wyjściowe PRNG i budować kandydatów seedów. Kolejny krok to wyprowadzenie adresów Bitcoin z każdego kandydata i porównanie ich z danymi publicznymi w blockchainie. Gdy seed generował adres z saldem, napastnik uzyskiwał kontrolę nad odpowiadającym mu kluczem prywatnym i przenosił środki. Przy ok. 40 bitach entropii pula to ok. bilion możliwości — liczba duża, ale wykonalna przy współczesnym sprzęcie, zwłaszcza po zawężeniu celów do seedów tworzonych w okresie 2021–2026. Galaxy Research oceniło, że fale 1 i 2 mogły mieć tego samego operatora. Inne zachowanie on-chain w fali 3 sugeruje, że podatność mogła zostać niezależnie odkryta i wykorzystana przez kolejnego sprawcę. Modele zagrożone: co decyduje o ryzyku O ryzyku nie przesądza to, jaki firmware jest dziś w urządzeniu, tylko wersja, na której seed został pierwotnie wygenerowany. Aktualizacja nie "naprawia" istniejącego seeda. Chroni wyłącznie przyszłe generowanie. Zakres według modeli (na podstawie komunikatów Coinkite): - Mk2 / Mk3: seedy tworzone na v4.0.0 / v4.0.1 do v4.1.9 — ok. 40 bitów entropii; poprawka od v4.2.0+. Najwyższe ryzyko; słabe seedy były aktywnie eksploatowane. - Mk4 / Mk5: seedy tworzone przed v5.6.0 (standard) / przed v6.6.0X (Edge) — ok. 72 bity; poprawka od v5.6.0+ / v6.6.0X+. Brak potwierdzonej masowej eksploatacji, ale entropia wciąż poniżej standardu. - Q: seedy tworzone przed v1.5.0Q (standard) / przed v6.6.0QX (Edge) — ok. 72 bity; poprawka od v1.5.0Q+ / v6.6.0QX+. Wyjątek: użytkownicy, którzy podczas tworzenia seeda dodali co najmniej 50 niezależnych i prywatnych rzutów kością, wprowadzili zewnętrzną, rzeczywistą entropię, która neutralizuje słabość PRNG. Tacy użytkownicy mają minimalne ryzyko w kontekście tej konkretnej podatności. Silna passphrase BIP39 utrudnia brute force, ale nie wzmacnia samego seeda — rekomendacja migracji pozostaje aktualna. Reakcja Coinkite: poprawki i krytyka Coinkite opublikowało pierwsze ostrzeżenia 30 i 31 lipca, ok. 30 godzin po rozpoczęciu szerokiego opróżniania adresów. Firma wypuściła łatki dla wszystkich modeli: v4.2.0 (Mk3), v5.6.0 (Mk4/Mk5) i v1.5.0Q (Q), a także analizę techniczną i instrukcję migracji. 1 sierpnia zaktualizowano advisory, rozszerzając zakres o Mk4, Mk5 i Q. Krytyka dotyczy przede wszystkim tego, że błąd pozostawał w produkcji pięć lat mimo przeglądów oraz że ostrzeżenie pojawiło się z opóźnieniem, gdy kradzież wciąż trwała. Badacz Wizardsardine Kevin Loaec zwracał też uwagę na ryzyko w konfiguracjach multisig z kluczami pochodzącymi z podatnych seedów, co w komunikacie Coinkite nie zostało w pełni domknięte. Co powinni zrobić poszkodowani: migracja, nie sama aktualizacja Sama aktualizacja firmware nie zabezpiecza portfela, jeśli seed został już wygenerowany na podatnej wersji. Należy stworzyć nowy seed na załatanym firmware i przenieść środki na nowe adresy. Rekomendowany proces (wg zaleceń Coinkite i przewodników technicznych): 1) Zaktualizuj firmware do najnowszej, poprawionej wersji dla danego modelu i ścieżki wydania; pobieraj wyłącznie ze strony Coinkite. 2) Wygeneruj całkowicie nowy seed na zaktualizowanym urządzeniu (nie przywracaj starego). Dla dodatkowej entropii rozważ co najmniej 50 prywatnych rzutów kością. 3) Zweryfikuj kopię zapasową seeda na urządzeniu; porównaj adres odbiorczy w aplikacji z adresem na ekranie Coldcard. 4) Przenieś całe saldo BTC ze starych adresów na adresy wynikające z nowego seeda, weryfikując dane transakcji na urządzeniu. 5) Potwierdź migrację w eksploratorze blockchain: transakcje mają być zatwierdzone, stare adresy puste, nowe saldo kompletne. 6) Dopiero wtedy bezpiecznie zniszcz stare kopie seeda i usuń wszelkie kopie fizyczne oraz cyfrowe. Użytkownicy multisig powinni dodatkowo wymienić każdy klucz pochodzący z podatnego seeda, sprawdzić próg podpisów i dopiero po weryfikacji nowej konfiguracji przenosić większe środki. Migracja wymaga transakcji on-chain, więc należy uwzględnić opłaty sieciowe. Szerszy kontekst: samokustodia wymaga także dobrej losowości Incydent przypomina, że bezpieczeństwo samokustodii opiera się nie tylko na kontroli kluczy, ale też na jakości generowania losowości. To kolejna poważna awaria PRNG w branży po "Milk Sad" (2023) i "Ill Bloom" (2026). Kod Coldcard jest publicznie dostępny, a mimo to błąd nie został zauważony przez lata — co pokazuje, że sama jawność kodu nie gwarantuje bezpieczeństwa, choć umożliwia audyt społeczności. CoinDesk zwracał uwagę, że takie zdarzenia mogą skłaniać część inwestorów ku ETF-om na Bitcoina. ETF ogranicza ryzyka operacyjne związane z generowaniem i ochroną kluczy, ale przenosi odpowiedzialność na instytucjonalnego powiernika. Zastrzeżenie: materiał ma charakter informacyjny i edukacyjny; nie stanowi porady inwestycyjnej, prawnej ani bezpieczeństwa. FAQ — najczęstsze pytania Czy mój Coldcard jest skompromitowany? Ryzyko jest wysokie, jeśli seed powstał na Mk2 lub Mk3 z firmware v4.0.0–v4.1.9 bez dodania wystarczającej entropii z rzutów kością. Seedy Mk4/Mk5/Q wygenerowane przed poprawkami mają ok. 72 bity entropii; brak potwierdzonej masowej eksploatacji, ale poziom pozostaje poniżej 128 bitów. Zalecenie: aktualizacja, nowy seed, migracja środków. Czy aktualizacja firmware rozwiązuje problem? Nie. Aktualizacja naprawia generowanie seedów w przyszłości, ale nie wzmacnia seeda już utworzonego na podatnym firmware. Konieczny jest nowy seed i transfer BTC na nowe adresy. Czy Ledger i Trezor są zagrożone? Nie. Ledger, Trezor i Block (Bitkey) deklarują inne metody generowania entropii, więc ta konkretna podatność Coldcard ich nie dotyczy. Ile BTC skradziono? Na 2 sierpnia 2026 r.: ok. 1 367 BTC (ok. 89 mln USD) w trzech falach, z 4 585 adresów. Analiza trwa; liczby mogą się jeszcze zmienić. Czy wiadomo, kto stoi za atakiem? Sprawca nie został zidentyfikowany. Galaxy Research sugeruje wspólnego operatora dla fal 1 i 2, natomiast inne zachowanie w fali 3 może wskazywać na niezależnego atakującego. Zgłoszono ok. 600 podejrzanych adresów. Czy rzuty kością mnie chronią? Tak, jeśli dodano co najmniej 50 niezależnych i prywatnych rzutów kością podczas tworzenia seeda. To dostarcza realnej zewnętrznej entropii, której wadliwy generator nie jest w stanie zredukować. Coinkite podaje, że poprawnie wykonany proces rzutów kością oznacza minimalne ryzyko w ramach tej podatności.