Użytkownicy z Kanady odpowiadają za 25% strat spowodowanych luką w zabezpieczeniach Coldcard

Rozkład geograficzny strat

Kanadyjscy posiadacze bitcoinów okazali się największą grupą demograficzną dotkniętą trwającym atakiem na portfel sprzętowy Coldcard, ponosząc 25% wszystkich przypisanych strat. Analitycy zauważają, że ta silna koncentracja regionalna pokrywa się z silną lokalną obecnością spółki macierzystej Coldcard, Coinkite, której siedziba znajduje się w Toronto.

Według analiz wizualnych przeprowadzonych przez Chainalysis Australia zajmuje drugie miejsce wśród krajów najbardziej dotkniętych atakiem, odpowiadając za 15% do 20% całkowitych strat. Tuż za nimi plasują się Stany Zjednoczone i Tajlandia, gdzie straty mieszczą się w przedziale od 10% do 15%. Chociaż atak najsilniej dotknął anglojęzyczne jurysdykcje oraz te, które wcześnie przyjęły bitcoina, dane wskazują na szerokie globalne skutki w Europie Zachodniej, Ameryce Łacińskiej oraz kluczowych afrykańskich ośrodkach kryptowalutowych, takich jak Nigeria i RPA.

Łączna wartość skradzionych aktywów w wyniku tego incydentu wyniosła 116 milionów dolarów. W analizie tego ataku firma Galaxy Research zidentyfikowała aktualizację oprogramowania sprzętowego z marca 2021 r. – a konkretnie wdrożenie nowego generatora liczb losowych – jako pojedynczy punkt awarii, który umożliwił przeprowadzenie ataku.

„Problem polegał na tym, że zostało ono nieprawidłowo skonfigurowane i domyślnie przełączało się na słabszy generator. Awaria przebiegała w sposób niewidoczny, bez żadnego ostrzeżenia. Nikt nie wiedział, że klucze prywatne były generowane z niską entropią” – stwierdziła firma Galaxy Research. „Pięć lat później atakujący w ciągu 41 minut wykradł 70 mln dolarów z 1200 portfeli”.

Wyjaśniając, dlaczego standardowe kontrole nie wykryły tego błędu przez ponad pięć lat, Natalie Newson, starszy badacz ds. łańcuchów bloków w firmie CertiK, ujawniła, że podstawową przyczyną był konkretny błąd konfiguracyjny: zmienna MICROPY_HW_ENABLE_RNG została ustawiona na zero.

„Dla statycznej instrukcji kontrolnej #ifndef makro ustawione na 0 jest nadal zdefiniowane” – wyjaśniła Newson. „Kontrola bezpieczeństwa zwróciła wartość true, pomijając instrukcję kontrolną #error i pozwalając systemowi kompilacji kontynuować pracę tak, jakby wszystko było poprawnie skonfigurowane”.

Protokoły reagowania na incydenty i awaryjnego usuwania usterek

Aby zapobiec podobnym cichym przejściom na pseudolosowość oprogramowania, Newson wezwała producentów do gruntownej zmiany standardów architektonicznych. „Najskuteczniejszym środkiem kontroli jest usunięcie rezerwy z produkcji i posiadanie dokładnie jednego zatwierdzonego dostawcy generatora liczb losowych (RNG)” – podkreśliła, zaznaczając, że cała ścieżka od pozyskania entropii do generowania nasion musi ściśle mieścić się w granicach walidacji określonych przez normę NIST FIPS 140-3.

W kontekście zarządzania ryzykiem operacyjnym związanym z pośpiesznym wydawaniem awaryjnych poprawek podczas trwania aktywnych automatycznych skanowań Newson podkreśliła, że w reagowaniu na incydenty priorytetem musi być komunikacja z użytkownikami równolegle z testami technicznymi.

„Priorytetem powinno być natychmiastowe poinformowanie o zakresie luki, zidentyfikowanie użytkowników, których dotyczy problem, oraz zapewnienie jasnych wytycznych dotyczących łagodzenia skutków, przy jednoczesnej dokładnej weryfikacji każdej poprawki przed jej wydaniem” – stwierdziła Newson, dodając, że przejrzystość jest równie istotna jak sama poprawka.

Użytkownikom nietechnicznym, którzy posiadają naruszone frazy seed i obawiają się zablokowania swoich urządzeń podczas awaryjnych aktualizacji oprogramowania układowego, Newson zalecił ścisły protokół naprawczy: po pierwsze, użytkownicy powinni zaopatrzyć się w zaufany portfel sprzętowy, wygenerować nową frazę seed w trybie offline oraz zweryfikować konfigurację za pomocą niewielkiej transakcji testowej. Następnie powinni przenieść wszystkie pozostałe środki na nowo zweryfikowaną konfigurację przed podjęciem jakichkolwiek prób aktualizacji oprogramowania układowego na oryginalnym urządzeniu.

Newson wezwał również użytkowników do unikania tworzenia pojedynczego punktu awarii poprzez korzystanie z portfeli sprzętowych różnych producentów w celu rozłożenia ryzyka na wiele kont.

Punkt zwrotny w dyskusjach na temat samodzielnego przechowywania kryptowalut

Incydent ten sprawił, że branża samodzielnego przechowywania kryptowalut i jej zwolennicy stanęli przed fundamentalnymi pytaniami dotyczącymi standardowych modeli bezpieczeństwa. Krytycy wskazują na nagłe wyczerpanie nieaktywnych, długoterminowych zasobów jako dowód na to, że samo wykonywanie operacji w trybie offline nie gwarantuje absolutnej ochrony.

Nanak Nihal Khalsa, współzałożyciel Human.tech, argumentował, że incydent ten podkreśla utrzymujące się ryzyko związane z podmiotami zewnętrznymi w ekosystemach sprzętowych.

„Hasło »Nie masz kluczy, nie masz monet« pomija ważny fakt: zawsze zlecasz komuś zaufanie, nawet w przypadku samodzielnego przechowywania. To tylko kolejny dowód na to, że samodzielne przechowywanie nie zmienia tego faktu” – zauważył Khalsa, ostrzegając, że pojawiające się wektory zagrożeń, takie jak ataki wspomagane sztuczną inteligencją, prawdopodobnie spotęgują te ryzyka.

Newson z firmy CertiK podzielił obawy dotyczące konfiguracji z pojedynczym podpisem, zauważając, że powszechne przyjęcie tej technologii wymaga systemów zbudowanych z uwzględnieniem płynnej degradacji, w których pojedynczy błąd – popełniony przez użytkownika lub dostawcę – nie doprowadzi do utraty oszczędności życia użytkownika.

„Samodzielne przechowywanie z pojedynczym podpisem nie pozostawia żadnego marginesu na błąd” – powiedział Newson. „Użytkownicy polegający na jednym urządzeniu pokładają zaufanie w fizycznym sprzęcie, kodzie i wszystkich jego zależnościach, a także w kontrolach jakości mających na celu wykrycie ewentualnych problemów”.

W związku z tym konsensus branżowy przesuwa się w kierunku rozwiązań opartych na wielu dostawcach, wielokrotnym podpisie lub podpisie progowym (MPC) jako niezbędnego standardu.

„Tak, powinno to być domyślnym standardem” – podsumował Newson. „Celem jest odejście od »zaufania do jednego urządzenia« na rzecz zapewnienia, że żaden pojedynczy skompromitowany komponent ani podmiot nie będzie w stanie przesunąć środków. W praktyce klucze podpisujące lub udziały progowe powinny obejmować niezależne obszary awarii organizacyjnych i technologicznych, tak aby żaden dostawca nie mógł samodzielnie odtworzyć klucza ani autoryzować transakcji”.