Podejrzewana czwarta fala ataków na Coldcard: Dlaczego nadal opróżnianych jest 462 adresów?

Szef działu badawczego Galaxy, Alex Thorn, zidentyfikował to, co wydaje się być czwartą zorganizowaną falą kradzieży Bitcoinów, obejmującą ziarna (seeds) wygenerowane przez dotknięte problemem oprogramowanie Coldcard. W okresie około 2,5 godziny między blokami 960 778 a 960 792 badacze zaobserwowali 218 transakcji obejmujących 462 podejrzane adresy ofiar, 216 nowych adresów docelowych oraz 388,92748828 BTC. Podobne transakcje reportedly pozostały w mempoolu, podczas gdy potwierdzone transakcje miały włączoną funkcję replace-by-fee (RBF).

Działania te sugerują, że publiczne ujawnienie problemu i awaryjne aktualizacje oprogramowania nie wyeliminowały ryzyka związanego z wcześniej wygenerowanymi ziarnami. Obserwowana szybkość opróżniania portfeli osiągnęła 13,8 na blok, w porównaniu do 0,3 w oknie kontrolnym przed incydentem – co stanowi około 45-krotny wzrost. Niemniej jednak „czwarta fala” pozostaje klasyfikacją badawczą opartą na wzorcach on-chain. Dowody nie identyfikują jednoznacznie sprawców ani nie dowodzą, że ta sama jednostka przeprowadziła każdą z fal.

Kluczowe wnioski

• Podejrzana czwarta fala obejmowała 218 transakcji, 462 podejrzane adresy ofiar, 216 nowych adresów docelowych oraz 388,92748828 BTC.
• Koncentracja aktywności i około 45-krotny wzrost szybkości opróżniania portfeli wspierają interpretację systematycznego wykorzystywania luki, a nie zwykłej migracji portfela.
• Przeważające transfery 1:1, minimalne ponowne wykorzystanie adresów docelowych oraz ruchy drugiego stopnia mogą wskazywać na bardziej rozproszoną strategię zarządzania środkami.
• Aktualizacja oprogramowania Coldcard nie naprawia istniejącego słabego ziarna; potencjalnie dotknięci użytkownicy muszą wygenerować nowe ziarno poprzez skorygowany proces i przenieść swoje aktywa.

Co wydarzyło się podczas podejrzanej czwartej fali ataku?

Zgodnie z monitorowaniem Thorna, najnowszy klaster transakcji pojawił się między blokami Bitcoina 960 778 a 960 792. W ciągu około 2,5 godziny badacze zidentyfikowali 218 transakcji dzielących cechy charakterystyczne dla trwającego incydentu Coldcard. Transakcje te obejmowały 462 adresy sklasyfikowane jako podejrzane adresy ofiar, 216 nowych adresów docelowych oraz 388,92748828 BTC. Podobne transakcje reportedly nadal oczekiwały na potwierdzenie w mempoolu, co sugeruje, że obserwowane okno czasowe może nie oznaczać końca aktywności.

Wcześniej potwierdzone transakcje również umożliwiały RBF, co pozwala na zastąpienie niepotwierdzonej transakcji Bitcoin wersją z wyższą opłatą. RBF jest normalną funkcją sieci i samodzielnie nie dowodzi złych intencji. W kontekście trwającego masowego opróżniania portfeli, jego użycie sugeruje jednak, że podmiot inicjujący transakcje aktywnie zarządzał priorytetem potwierdzeń i mógł zwiększać opłaty w przypadku pojawienia się konkurencyjnych transakcji.

Zgłoszone liczby adresów i wartości wymagają ostrożnej interpretacji. „Adres ofiary” to adres sklasyfikowany przez badaczy na podstawie jego zachowania transakcyjnego i powiązania z odpowiednią granicą oprogramowania Coldcard; niekoniecznie reprezentuje on jednego indywidualnego użytkownika. Jeden portfel może kontrolować wiele adresów, a transakcja może wydawać kilka wejść. Podobnie, 388,92748828 BTC zaobserwowanych w tym oknie nie powinno być automatycznie dodawane do wcześniejszych szacunków strat, dopóki badacze nie potwierdzą, że adresy, wejścia i przelane środki nie pokrywają się z poprzednimi klastrami.

Najważniejszym dowodem jest intensywność i spójność aktywności. Badacze obliczyli 13,8 opróżnień na blok w monitorowanym okresie, w porównaniu do 0,3 na blok w oknie kontrolnym przed incydentem. Tak gwałtowny wzrost trudno wyjaśnić wyłącznie jako reakcję niezależnych użytkowników na ostrzeżenie bezpieczeństwa. Transakcje reportedly nie zawierały również żadnych wejść sprzed odpowiedniej granicy oprogramowania Coldcard, co wzmacnia powiązanie między opróżnianymi środkami a ziarnami utworzonymi pod wpływem dotkniętego problemem oprogramowania.

Ocena Galaxy opiera się zatem na łącznym ciężarze timing'u, wyboru adresów, konstrukcji transakcji i zachowania adresów docelowych. Żadna pojedyncza cecha nie jest rozstrzygająca: legalni użytkownicy mogą włączać RBF, generować nowe adresy odbiorcze lub jednocześnie migrować środki po oficjalnym ostrzeżeniu. Interpretacja zorganizowanego ataku staje się bardziej przekonująca, gdy te cechy pojawiają się z niezwykłą regularnością wśród setek adresów powiązanych z oprogramowaniem.

Jednak analiza on-chain nie może bezpośrednio ujawnić, kto kontroluje klucze prywatne. Jeden atakujący mógł zmieniać strategie transakcyjne między falami, podczas gdy kilku operatorów mogło niezależnie wykorzystać tę samą słabość po jej upublicznieniu. Galaxy w konsekwencji traktuje klastry jako skoordynowane fale ataków, nie twierdząc jednocześnie, że każda fala została definitywnie przypisana tej samej jednostce.

Co ujawnia nowa topologia transakcji?

Podejrzana czwarta fala wykazywała przeważającą strukturę 1:1, w której środki z adresów ofiar były wysyłane na oddzielne nowe adresy docelowe. Tylko jeden adres docelowy reportedly otrzymał dwa opróżnienia, a w początkowym okresie monitorowania nie pojawił się żaden oczywisty centralny adres agregacyjny. Część środków następnie przeniesiono na adresy drugiego stopnia.

Ta struktura różni się od najwyraźniejszych odcisków palców obserwowanych wcześniej w trakcie incydentu. Analiza Galaxy wykazała, że pierwsze dwie główne fale wielokrotnie używały zakodowanych na sztywno opłat w wysokości 30 sat/vB i podobnych wzorców wsadowych, co wspiera możliwość wspólnego operatora lub narzędzia atakującego. Późniejsza fala przesunęła się w kierunku indywidualnych transferów i rozproszonych miejsc docelowych. W pierwszych trzech zidentyfikowanych falach raporty powiązane z Galaxy określiły dotkniętą kwotę na 1 367,05 BTC z 4 585 adresów, podkreślając jednocześnie, że różnice w odciskach palców transakcji uniemożliwiły definitywne przypisanie ich jednemu atakującemu.

Jednym z wyjaśnień jest to, że atakujący uznał, iż scentralizowane adresy zbiorcze ułatwiały grupowanie i monitorowanie wcześniejszych transakcji, a następnie przyjął nowe miejsca docelowe i dodatkowe skoki, aby zmniejszyć natychmiastową widoczność. Innym jest to, że ujawnienie słabości umożliwiło naśladowcom poszukiwanie pozostałych podatnych ziaren przy użyciu niezależnie opracowanych narzędzi. Obie interpretacje są zgodne ze wzorcami transakcji, ale żadnej z nich nie można udowodnić wyłącznie na podstawie topologii.

Transfery drugiego stopnia nie powinny być automatycznie określane jako pranie pieniędzy. Mogą one oddzielać początkową ekstrakcję od długoterminowego przechowywania, przygotowywać środki do późniejszej konsolidacji, testować, czy adresy zostały oznaczone, lub kierować aktywa do usług zewnętrznych. Śledczy będą musieli ustalić, czy adresy drugiego stopnia ostatecznie zbiegają się lub wchodzą w interakcje z identyfikowalnymi podmiotami. Na tym etapie obronnym wnioskiem jest to, że najnowsze transakcje pokazują systematyczne opróżnianie połączone z coraz bardziej rozproszonym zarządzaniem środkami.

Ewolucja ataków zmienia również praktyczne ryzyko dla użytkowników. Galaxy zidentyfikowało początkowy wybuch, w którym 1 082,65 BTC zostało opróżnionych z 1 196 adresów w ciągu około 41 minut. Późniejsza aktywność celowała w dodatkowe adresy i mniejsze salda, stosując różne struktury. Może to wskazywać na przejście od szybkiej ekstrakcji widocznych portfeli o wysokiej wartości do ciągłego skanowania pozostałej populacji słabych ziaren.

Kontynuująca się kampania enumeracji może ponownie odwiedzać tę samą przestrzeń podatnych ziaren i celować w mniejsze salda, w miarę jak narzędzia atakujące się poprawiają lub koszty transakcji się zmieniają. Publiczne ujawnienie może również stworzyć wyścig między legalnymi właścicielami próbującymi migrować swoje środki a atakującymi próbującymi odtworzyć ich klucze. Podejrzana czwarta fala jest więc ważna nie tylko ze względu na swoją obserwowaną wartość, ale dlatego, że wskazuje, iż niezmigrowane ziarna mogą pozostać podatne na eksploatację nawet po zakończeniu najbardziej widocznych początkowych kradzieży.

Techniczna przyczyna źródłowa: Przewidywalna losowość

Zespół Inżynierii i Bezpieczeństwa Bitcoin firmy Block prześledził podstawowy problem do integracji oprogramowania Coldcard z jego ścieżką generowania liczb losowych. Według Blocka, konfiguracja mająca na celu wyłączenie implementacji sprzętowego RNG MicroPythona spowodowała, że zewnętrzna biblioteka cofnęła się do deterministycznego generatora oprogramowania Yasmarang, zamiast do oczekiwanego sprzętowego RNG STM32. Biblioteka sprawdzała, czy makro konfiguracji istnieje, ale nie czy było włączone.

Dla dotkniętego problemem oprogramowania Mk2 i Mk3, generator awaryjny mógł być inicjowany przy użyciu metadanych urządzenia i stanu czasowego bez otrzymywania kryptograficznie bezpiecznej entropii przez podatną ścieżkę. Jeśli atakujący mógłby określić lub wystarczająco ograniczyć UID urządzenia, stan timera i poprzednie wywołania liczb losowych, kandydujące wyniki mogłyby zostać potencjalnie odtworzone offline. W nowszych urządzeniach dodano dane wejściowe z bezpiecznego elementu, ale Block zgłosił, że tylko cztery bajty wynikowego skrótów trafiły do funkcji reseedingu, ograniczając bezpiecznie zróżnicowany stan do nie więcej niż (2^{32}) możliwości przy założeniu odpowiednich warunków.

Przepuszczenie słabego wyniku losowego przez kryptograficzny hash nie rozwiązuje problemu. Hash może sprawić, że wyniki będą wyglądać na równomiernie rozłożone, ale nie może stworzyć więcej możliwych sekretów niż istniało w oryginalnej przestrzeni wejściowej. Atakujący może wyliczyć kandydujące ziarna, wyprowadzić ich adresy Bitcoin i porównać te adresy z publicznym blockchainem. Dopasowanie dostarcza sygnału walidacyjnego, który może ujawnić odpowiadający klucz prywatny bez fizycznego dostępu do portfela.

Nie jest to awaria systemu podpisów Bitcoina ani standardów ziaren. Luka dotyczy losowości używanej przed utworzeniem kluczy prywatnych. Gdy istnieje już słabe ziarno, urządzenie offline, odizolowane powietrzem (air-gapped) lub fizycznie zabezpieczone nie może zapobiec odtworzeniu tego samego sekretu przez inną stronę za pomocą obliczeń.

Block opisał swój raport jako wczesną ocenę techniczną opublikowaną, gdy eksploatacja wydawała się być aktywna, i zauważył, że nie zakończył empirycznych testów każdej możliwej ścieżki ataku. Jego ustalenia należy zatem rozpatrywać wraz z dochodzeniem Coinkite i końcowymi wnioskami technicznymi. Nawet z tym zastrzeżeniem, centralny problem bezpieczeństwa jest jasny: zabezpieczenia zastosowane po generowaniu kluczy nie mogą przywrócić entropii, której brakowało w momencie tworzenia ziarna.

Dlaczego aktualizacja oprogramowania nie wystarczy?

Oficjalne wytyczne Coinkite rozróżniają zapobieganie generowaniu podatnych ziaren w przyszłości a naprawę istniejącego ziarna. Naprawione oprogramowanie zmienia sposób generowania nowych sekretów, ale nie może zmienić mnemonika utworzonego pod wpływem dotkniętej wersji. Importowanie tego mnemonika do zaktualizowanego oprogramowania lub innego portfela sprzętowego odtwarza te same klucze prywatne i zachowuje podstawowe ryzyko. Pełne zaradzenie wymaga wygenerowania zupełnie nowego ziarna poprzez skorygowany proces i przeniesienia środków on-chain.

Coinkite identyfikuje ziarna Mk2 i Mk3 wygenerowane na wersjach oprogramowania od 4.0.1 do 4.1.9 jako dotknięte problemem. Firma zaleca również migrację dla ziaren Mk4 i Mk5 utworzonych przed standardowym oprogramowaniem 5.6.0 lub Edge firmware 6.6.0X, a także ziaren Coldcard Q utworzonych przed standardowym oprogramowaniem 1.5.0Q lub Edge firmware 6.6.0QX. Firma opisuje wpływ na Mk4, Mk5 i Q jako mniej poważny niż na dotknięte urządzenia Mk2 i Mk3, ale wciąż istotny. Właściciele Mk2 i Mk3 mogą generować ziarna zastępcze po zainstalowaniu wersji 4.2.0 lub nowszej.

Prawdziwie niezależna entropia może zapewniać ograniczone wyjątki. Coinkite stwierdza, że co najmniej 50 uczciwych, niezależnych i prywatnych rzutów kostką może contribute 128 bitów entropii, podczas gdy 99 lub więcej rzutów contribute około 256 bitów. Użytkownicy, którzy nie mogą pewnie potwierdzić, jak rzuty zostały wygenerowane i uwzględnione, nie powinni polegać na tym wyjątku. Silne hasło BIP-39 może stworzyć dodatkową barierę, ale Coinkite nadal zaleca migrację, ponieważ hasło nie naprawia oryginalnego ziarna. PIN Coldcard nie jest hasłem BIP-39 i nie zapobiega przenoszeniu środków blockchain, jeśli klucze prywatne zostaną odtworzone.

Co powinni teraz zrobić użytkownicy Coldcard?

Potencjalnie dotknięci użytkownicy powinni ustalić model urządzenia i wersję oprogramowania użytą w momencie pierwotnego wygenerowania bieżącego ziarna. Sama bieżąca wersja oprogramowania jest niewystarczająca, jeśli ziarno zostało utworzone na starszym Coldcardu lub zaimportowane z innego urządzenia. Sprawdzanie i pobieranie oprogramowania powinno odbywać się wyłącznie przez oficjalne kanały Coinkite, bez klikania w linki dostarczane przez nieproszone konta wsparcia, wiadomości w mediach społecznościowych lub usługi odzyskiwania.

Użytkownicy znajdujący się w dotkniętym zakresie powinni zainstalować odpowiednie naprawione oprogramowanie i wygenerować całkowicie nowe ziarno. Powinni bezpiecznie zapisać nową kopię zapasową, zweryfikować odcisk palca portfela i adres odbiorczy bezpośrednio na ekranie sprzętu oraz wysłać małą transakcję testową przed przeniesieniem pozostałego salda. Przywrócenie starego mnemonika na nowym urządzeniu lub kontynuowanie jego używania po aktualizacji oprogramowania nie rozwiązuje luki.

Incydent stwarza również okazję do wtórnego oszustwa. Użytkownicy nigdy nie powinni ujawniać słów ziarna, kluczy prywatnych, haseł, sekwencji rzutów kostką ani kopii zapasowych portfela nikomu, kto twierdzi, że reprezentuje Coldcard, Coinkite, Galaxy, giełdę, organy ścigania lub firmę odzyskującą. Legalny personel wsparcia nie potrzebuje tych sekretów do weryfikacji oprogramowania lub wyjaśniania procedur migracji.

Użytkownicy multisignature powinni ocenić, ile dotkniętych kluczy uczestniczy w progu wydatków. Jeśli wystarczająca liczba podatnych kluczy może zostać odtworzona, ochrona multisignature może również zawieść. Zastępowanie kluczy bez osłabiania progu lub niepotrzebnego ujawniania skryptów portfela może wymagać bardziej starannie zaplanowanej migracji, szczególnie w przypadku portfeli o wysokiej wartości lub zarządzanych instytucjonalnie.

Szersze implikacje dla bezpieczeństwa portfeli sprzętowych

Incydent nie dowodzi, że wszystkie portfele sprzętowe lub systemy self-custody są niebezpieczne. Pokazuje, że bezpieczeństwo portfela zależy od całego cyklu życia klucza: generowania entropii, konfiguracji oprogramowania, przeglądu zależności, kopii zapasowej ziarna, weryfikacji transakcji i ewentualnej migracji. Etykiety takie jak „air-gapped”, „offline”, „open source” lub „chronione bezpiecznym elementem” opisują indywidualne mechanizmy obronne, a nie bezpieczeństwo całego systemu.

Oprogramowanie open source umożliwia niezależny przegląd, ale nie gwarantuje, że błędy implementacji zostaną odkryte przed eksploatacją. Silniejsze assurance wymaga reprodukowalnych buildów, testowania entropii, przeglądu kodu across library boundaries, deterministycznych wektorów testowych i zachowania fail-closed, gdy bezpieczna losowość jest niedostępna. W przeciwnym razie portfel może nadal otrzymywać środki i podpisywać ważne transakcje, ukrywając słabość, która istniała od momentu utworzenia ziarna.

Główną lekcją jest pochodzenie ziarna. Przeniesienie starego mnemonika na nowszy sprzęt poprawia środowisko jego przechowywania, ale nie zmienia jego bezpieczeństwa matematycznego. Portfele sprzętowe chronią sposób przechowywania i używania kluczy prywatnych; nie mogą retroaktywnie sprawić, by przewidywalne ziarno stało się nieprzewidywalne.

Wniosek

Podejrzana czwarta fala ataku Coldcard wskazuje, że okno ryzyka pozostaje otwarte. Skompresowany timing, około 45-krotny wzrost szybkości opróżniania, granica wejść powiązana z oprogramowaniem i regularna struktura transakcji wspierają ocenę Galaxy dotyczącą systematycznej aktywności. Tożsamości atakujących i relacje między różnymi falami pozostają jednak niepotwierdzone.

Dla potencjalnie dotkniętych użytkowników priorytetem jest zweryfikowanie, kiedy i jak utworzono ich bieżące ziarno. Naprawione oprogramowanie może chronić nowo wygenerowane sekrety, ale nie może naprawić istniejącego słabego ziarna. Skutecznym rozwiązaniem jest wygenerowanie nowego ziarna poprzez skorygowany proces i bezpieczna migracja aktywów.

Zastrzeżenie dotyczące ryzyka: Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady inwestycyjnej, prawnej ani dotyczącej cyberbezpieczeństwa. Użytkownicy powinni weryfikować wersje oprogramowania i procedury migracji za pośrednictwem oficjalnej dokumentacji Coinkite oraz szukać wykwalifikowanej pomocy w przypadku złożonych konfiguracji portfeli.