Napisane przez: imToken
Portfel sprzętowy z nienaruszonymi oryginalnymi układami, autentycznym oprogramowaniem układowym, a nawet zdolny do pomyślnego przejścia oficjalnego Genuine Check — czy znajdujące się w nim aktywa nadal mogą zostać skradzione przez hakerów?
Niedawny incydent bezpieczeństwa Ledger dokładnie ujawnił to pozornie niemożliwe ryzyko.
Zgodnie z wynikami śledztwa ujawnionymi następnie przez zespół ds. bezpieczeństwa Ledger, atakujący wszczepił dodatkowy złośliwy obwód wewnątrz dotkniętego urządzenia, który był w stanie przechwycić frazę mnemoniczną wyświetlaną na ekranie i wysłać ją do atakującego za pośrednictwem sieci komunikacji mobilnej.
Innymi słowy, oryginalny układ bezpieczeństwa nie został naruszony, ale fraza mnemoniczna mogła już trafić w ręce hakera przy pierwszym wyświetleniu na ekranie.
Co więcej, nie jest to jedyny incydent bezpieczeństwa wart uwagi w ostatnim czasie.
Od września, począwszy od Bitget, który napotkał wykorzystanie luki w produkcie bezpieczeństwa firmy trzeciej, przez dostawcę usług e-mail dla Trezor, firmę Brevo, która została naruszona, aż po problemy z bezpieczeństwem pojawiające się w niektórych elementach infrastruktury MetaMask, seria incydentów przypomina nam, że w miarę jak produkty Crypto stają się coraz bardziej złożone, bezpieczeństwo nie dotyczy już tylko ochrony kluczy prywatnych i unikania luk w inteligentnych kontraktach.
Ryzyka ukryte w obiegu urządzeń, usługach firm trzecich, uprawnieniach wewnętrznych i komunikacji z użytkownikami mogą równie dobrze stać się punktami wejścia, których poszukują atakujący.
I. Nowy alarm dotyczący „bezpieczeństwa łańcucha dostaw” ogłoszony przez Ledger
Najpierw przeanalizujmy, co tym razem przydarzyło się Ledger.
Kupując portfel sprzętowy, ludzie zazwyczaj są czujni wobec dwóch rzeczy: kupienia podróbki lub otrzymania urządzenia, które zostało wcześniej zainicjowane przez kogoś innego.
Najczęstszym trikiem we wczesnych latach było to, że złośliwi pośrednicy najpierw generowali frazę mnemoniczną, drukowali ją na zdrapce i wsuwali z powrotem do opakowania, licząc na to, że niedoświadczeni użytkownicy nie zrozumieją zasad i bezpośrednio wpłacą na nią środki.
Chociaż to oszustwo jest niebezpieczne, logika obrony jest bardzo jasna — korzystaj z legalnych kanałów, sprawdź stan urządzenia, obserwuj, jak urządzenie samo generuje nową frazę mnemoniczną, i nigdy nie używaj gotowej frazy mnemonicznej z pudełka.
Ale ten atak wymierzony w Ledger wyraźnie podniósł poziom metod. Haker wcisnął dodatkowy moduł elektroniczny z mikrokontrolerem, eSIM i możliwościami komunikacji komórkowej do wnętrza obudowy. Gdy użytkownicy inicjują portfel po raz pierwszy, ostatecznie będą musieli odczytać frazę mnemoniczną z ekranu i ją zapisać.
Innymi słowy, wszczepiony złośliwy obwód w ogóle nie zakłóca procesu generowania frazy mnemonicznej; jedynie monitoruje frazę mnemoniczną i bezpośrednio ją przesyła. To także wyjaśnia, dlaczego „klucz prywatny nie został bezpośrednio wyodrębniony z układu bezpieczeństwa” nie oznacza, że informacje do odzyskania portfela użytkownika są nadal bezpieczne.
Co bardziej kłopotliwe, nawet jeśli urządzenie przejdzie oficjalny Genuine Check, może nie być w stanie zidentyfikować tego dodatkowego sprzętu, ponieważ weryfikacja autentyczności potwierdza głównie tożsamość układu bezpieczeństwa i wiarygodność oprogramowania układowego.
Tak więc ten incydent rzeczywiście ujawnił poważne „ryzyko łańcucha dostaw”, które jest łatwe do przeoczenia w codziennym życiu: bezpieczeństwo portfela sprzętowego zależy nie tylko od układu i oprogramowania układowego, ale także od całego procesu dostawy od fabryki do rąk użytkownika.
W końcu urządzenie może przejść przez wiele ogniw, takich jak regionalni dystrybutorzy, magazyny firm trzecich, logistyka i sprzedawcy detaliczni. Każdy uczestnik mający możliwość fizycznego dostępu do urządzenia może stać się punktem ryzyka wymagającym dodatkowej oceny.
II. Od Trezora do Bitget: Jak atakujący omijają podstawowe zabezpieczenia?
Po zrozumieniu problemu Ledgera, jeśli następnie przyjrzymy się incydentom bezpieczeństwa, z którymi Bitget i Trezor spotkały się jeden po drugim w ostatnim czasie, odkryjemy, że leżąca u ich podstaw logika jest uderzająco podobna: atakujący również unikali najsilniejszej linii obrony frontalnej, a zamiast tego wchodzili od strony peryferyjnych „usług zewnętrznych”.
Najpierw spójrzmy na Trezor.
Na początku września niektórzy użytkownicy Trezora otrzymali e-mail z tematem „Krytyczny alert bezpieczeństwa: luka w entropii STM32”, twierdzący, że portfel sprzętowy ma poważną lukę w zabezpieczeniach i wymagane jest natychmiastowe działanie.
Takie e-maile łatwo wywołują u użytkowników nerwowość. W końcu, gdy w grę wchodzą portfele sprzętowe i luki w zabezpieczeniach, nikt nie chce, aby jego aktywa poniosły z tego powodu straty.
Dokładnie tak się stało: atakujący wykorzystał Brevo, platformę marketingu e-mailowego firmy zewnętrznej używaną przez Trezor, aby złośliwa treść dotarła do skrzynek odbiorczych użytkowników za pośrednictwem normalnej infrastruktury wysyłania e-maili.
Zgodnie z późniejszym raportem Brevo dotyczącym incydentu, atakujący wykorzystał wady granic uprawnień w swoim systemie jednokrotnego logowania, aby uzyskać nieautoryzowany dostęp do innych kont klientów, co ostatecznie objęło 138 kont klientów, z których część została wykorzystana do wysyłania e-maili phishingowych lub eksportowania danych kontaktowych.
Trezor następnie potwierdził, że w wyniku incydentu wyeksportowano 347 149 adresów kontaktowych e-mailowych do celów marketingowych, a e-maile atakujące próbowały nakłonić użytkowników do pobrania złośliwych aplikacji i wprowadzenia informacji o kopii zapasowej portfela.
Należy zauważyć, że w tym incydencie nie ma dowodów na to, że portfele sprzętowe Trezora lub systemy ochrony kluczy prywatnych zostały naruszone. Atakujący najpierw uzyskał informacje o użytkownikach oraz możliwość nadużycia oficjalnych kanałów komunikacji.
Jednak dla zwykłych użytkowników, którzy otrzymali te e-maile, rozpoznanie ryzyka stało się jeszcze trudniejsze, ponieważ e-maile mogły pochodzić ze znanej oficjalnej domeny i mogły również przejść normalne kontrole uwierzytelniania e-maili, podczas gdy treść została już zastąpiona przez atakującego informacjami phishingowymi.
Jeśli użytkownicy dobrowolnie wprowadzą z tego powodu swoją frazę mnemoniczną, to, co pierwotnie było jedynie problemem zewnętrznej usługi e-mailowej, może dalej przekształcić się w rzeczywiste straty aktywów.
Teraz spójrzmy na Bitget.
24 września w niektórych gorących i ciepłych portfelach Bitget doszło do nieautoryzowanych transferów aktywów, które ostatecznie zweryfikowano jako obejmujące około 388 milionów dolarów.
Zgodnie z wynikami śledztwa oficjalnie ogłoszonymi przez Bitget, atakujący wykorzystał lukę w produkcie bezpieczeństwa firmy zewnętrznej, aby uzyskać poświadczenia o wysokich uprawnieniach wewnątrz giełdy, następnie wtargnął do systemów zaplecza związanych z portfelami, sfałszował polecenia wypłaty, ominął pierwotne kontrole ryzyka i spowodował, że nieprawidłowe transfery weszły w normalny proces wykonania.
Bitget oświadczył, że w tym incydencie nie stwierdzono wycieku kluczy prywatnych, a zimne portfele nie zostały dotknięte. Brzmi to nieco sprzecznie: skoro klucze prywatne nie zostały skradzione, dlaczego pieniądze nadal mogły zostać przelane?
Właściwie nie jest to trudne do zrozumienia.
W przypadku platform powierniczych, takich jak giełdy, po zainicjowaniu wypłaty przez użytkownika nie jest tak, że osoba ręcznie podpisuje każdą transakcję kluczem prywatnym za każdym razem. Zamiast tego musi przejść przez cały zestaw wewnętrznych procesów, takich jak weryfikacja konta, przegląd kontroli ryzyka, generowanie transakcji i podpisywanie portfela.
To jest jak skarbiec bankowy. Nawet jeśli klucz do skarbca jest przechowywany bardzo rygorystycznie, jeśli ktoś może podszyć się pod wewnętrzną tożsamość o wysokich uprawnieniach i sfałszować polecenie przelewu, które przejdzie zatwierdzenie, środki w skarbcu nadal mogą zostać omyłkowo przelane.
To, co Bitget ujawnił tym razem, to dokładnie to, w jaki sposób ryzyko rozprzestrzenia się dalej do systemu wykonawczego aktywów, gdy uprawnienia nadrzędne i weryfikacja poleceń zawiodą. Dlatego „klucz prywatny nie wyciekł” i „środki nie zostaną nielegalnie przelane” to w rzeczywistości dwie różne rzeczy.
Jeśli chodzi o incydent bezpieczeństwa infrastruktury ujawniony przez MetaMask pod koniec września, przedstawiał on inny wymiar ryzyka operacyjnego.
W tym czasie MetaMask podjął środki zapobiegawcze i proaktywnie wycofał się z niektórych dotkniętych walidatorów stakingowych. Zgodnie z aktualizacją oficjalnego śledztwa z 1 października, nie znaleziono żadnych oznak, że portfele MetaMask lub środki klientów zostały dotknięte, a powiązana działalność stakingowa nie zarządza kluczami do wypłat w imieniu klientów.
Jednak nie oznacza to, że problemy infrastrukturalne nie będą miały innych skutków. Rozwiązania niepowiernicze rozwiązują głównie kwestię kontroli aktywów, ale nie mogą automatycznie wyeliminować ryzyka operacyjnego zewnętrznej infrastruktury.
Łącząc te wydarzenia razem, wątek jest w rzeczywistości bardzo jasny:
- To, co ujawnił Ledger, to ryzyko fizycznej manipulacji w procesie obiegu sprzętu, które może ostatecznie doprowadzić do kradzieży fraz mnemonicznych;
- To, co ujawnił Trezor / Brevo, to ryzyko wycieku informacji użytkowników i nadużycia oficjalnych kanałów komunikacji, co nie oznacza, że sam portfel został naruszony;
- To, co ujawnił Bitget, to ryzyko przeniesienia luk w produktach stron trzecich do wewnętrznych systemów o wysokich uprawnieniach, co może bezpośrednio wpłynąć na wykonanie transakcji funduszowych;
- MetaMask z kolei przypomina nam, że kontrola aktywów i ryzyko operacyjne usługi to nie to samo pojęcie.
Ogólnie rzecz biorąc, dzisiejsze produkty Crypto nie są już odizolowanymi wyspami.
Portfele polegają na zewnętrznych węzłach RPC do odczytu danych on-chain i na interfejsach agregacyjnych do pobierania kwotowań rynkowych; giełdy nie mogą obejść się bez zewnętrznego monitoringu bezpieczeństwa, weryfikacji KYC i komponentów kontroli ryzyka; rozciągając się jeszcze dalej na zewnątrz, istnieją również operatorzy węzłów, dostawcy chmury, zgłoszenia obsługi klienta i systemy poczty elektronicznej, takie jak Brevo.
Te zewnętrzne usługi sprawiają, że produkty działają wydajniej i poprawiają doświadczenie użytkownika, ale jednocześnie za każdym razem, gdy wprowadzana jest nowa zewnętrzna zależność, produkt zyskuje kolejną warstwę relacji zaufania, którymi trzeba zarządzać:
Do czego mają dostęp strony trzecie, jak duże mają uprawnienia i czy w przypadku ich naruszenia ryzyko będzie nadal przenoszone do innych systemów krytycznych?
III. Jak powinny bronić się produkty i użytkownicy?
W obliczu coraz bardziej złożonego ryzyka zależności od stron trzecich i wzajemnie powiązanych relacji zależności, oczekiwanie, że zespoły produktowe wycofają się do prymitywnego stanu „niepolegania na żadnych zewnętrznych usługach”, jest oczywiście nierealistyczne i nie odpowiada regułom rynkowym.
To, co naprawdę testuje umiejętności architektury bezpieczeństwa, to minimalizowanie każdej możliwej ekspozycji na ryzyko.
Na przykład, dlaczego dostawca SaaS, który zajmuje się wyłącznie wysyłaniem e-maili marketingowych, miałby długoterminowo przechowywać dane kontaktowe wszystkich użytkowników? Dlaczego narzędzia monitoringu bezpieczeństwa stron trzecich mogą uzyskać dostęp do podstawowego środowiska produkcyjnego bez niezależnej wielopoziomowej autoryzacji? Szczególnie w przypadku wrażliwych działań związanych z transferem funduszy systemy wewnętrzne nigdy nie mogą przyjmować „domyślnego zaufania” i muszą wdrażać ścisłą izolację uprawnień oraz niezależną weryfikację krzyżową.
To jest również to, co często nazywa się „najmniejszymi uprawnieniami” i „rozdzieleniem obowiązków” w architekturze bezpieczeństwa: platforma do wysyłania e-maili powinna mieć tylko uprawnienia wymagane do wysyłania e-maili, narzędzia monitoringu bezpieczeństwa nie powinny móc dowolnie wykonywać transferów funduszy, a duża wypłata nie powinna być zatwierdzana bezpośrednio wyłącznie na podstawie polecenia przesłanego z jakiegoś systemu wewnętrznego.
Incydent z Ledger dodatkowo przypomina producentom portfeli sprzętowych, że zarządzanie bezpieczeństwem musi obejmować nawet fizyczny proces obiegu produktu.
Od wysyłki z fabryki, przez magazynowanie, logistykę, aż po dostawę do dealera – jak ustanowić proces zarządzania umożliwiający identyfikowalność, jak wykrywać nieprawidłowe demontaż lub wymianę urządzeń oraz jak po wystąpieniu problemu zlokalizować dotknięte partie i użytkowników – nie powinno być traktowane jako zwykła praca związana z zarządzaniem kanałami.
Ponieważ dla urządzenia sprzętowego chroniącego klucze prywatne sam proces dostawy jest częścią systemu bezpieczeństwa.
Oczywiście dla zwykłych użytkowników nie możemy ani audytować łańcucha dostaw oprogramowania portfela, ani badać po kolei każdego ogniwa magazynowania i logistyki portfela sprzętowego.
Ale nie oznacza to, że możemy jedynie biernie ponosić ryzyko. Przynajmniej kilka rzeczy warto wyrobić sobie jako nawyk w codziennym użytkowaniu.
Po pierwsze, zminimalizuj niepotrzebnych pośredników w procesie zakupu portfela sprzętowego.
Jeśli warunki na to pozwalają, w pierwszej kolejności zamawiaj z oficjalnej strony internetowej marki i wybierz wysyłkę bezpośrednio z fabryki lub oficjalnego magazynu, co zwykle zmniejsza szansę na to, że urządzenie po opuszczeniu kontroli fabryki zostanie dotknięte, rozmontowane lub podmienione przez osoby trzecie.
Z perspektywy zarządzania ryzykiem, im więcej niezależnych stron ma kontakt z urządzeniem, tym więcej ogniw wymaga dodatkowego zaufania; ponadto po otrzymaniu urządzenia nadal należy sprawdzić, czy opakowanie i wygląd nie budzą zastrzeżeń, użyć oficjalnego oprogramowania do przeprowadzenia weryfikacji i ściśle przestrzegać procesu inicjalizacji.
Po drugie, konieczne jest ponowne zrozumienie, czy „oficjalne wiadomości” są godne zaufania.
Incydent z Trezor pokazał już, że nawet jeśli e-mail rzeczywiście został wysłany przez oficjalnie używaną platformę usługową, nie oznacza to, że zawarte w nim linki i wymagania dotyczące operacji są z konieczności bezpieczne.
Zwłaszcza gdy w grę wchodzą wrażliwe operacje, takie jak aktualizacje portfela, blokady kont, migracja aktywów i poprawki luk w zabezpieczeniach, najlepiej nie klikać bezpośrednio linków w wiadomości, lecz aktywnie zweryfikować za pośrednictwem zapisanego adresu oficjalnej strony internetowej lub już zainstalowanej oficjalnej aplikacji.
W przypadku portfeli niepowierniczych, takich jak imToken, użytkownicy również muszą rozpoznawać oficjalne kanały, korzystać z token.im jako podstawy do pobrania i instalacji, a napotykając nietypowe informacje, w pierwszej kolejności weryfikować za pośrednictwem oficjalnych wejść, takich jak „Pomoc i opinie” w aplikacji.
Niezależnie od tego, czy druga strona twierdzi, że jest oficjalną obsługą klienta, zespołem ds. bezpieczeństwa, czy przedstawia pozornie bardzo profesjonalne wyjaśnienie luki w zabezpieczeniach, nigdy nie należy ujawniać jej frazy mnemonicznej ani klucza prywatnego.
Wreszcie, konieczne jest rozróżnienie rzeczywistego wpływu różnych incydentów bezpieczeństwa na siebie samego.
Wyciek adresu e-mail oznacza głównie, że w przyszłości możesz spotkać się z większą liczbą ukierunkowanych ataków phishingowych; kliknięcie podejrzanego linku wymaga dalszego potwierdzenia, czy nie pobrano lub nie uruchomiono złośliwych programów; jeśli fraza mnemoniczna została już wprowadzona, należy natychmiast potraktować to jako wyciek kontroli nad portfelem.
Jeśli podpisano podejrzane transakcje lub autoryzacje, konieczne jest również połączenie konkretnych operacji on-chain w celu ustalenia, czy istnieje ryzyko kontynuacji autoryzacji kontraktu.
Jeśli chodzi o awarie usług stron trzecich lub nieprawidłowości infrastruktury, tym bardziej należy odnieść się do oficjalnie ujawnionego zakresu wpływu, aby ustalić, czy dotyczy to twoich aktywów, dostępności usług lub zwrotów.
Nie można z góry zakładać wniosku, że klucz prywatny został skompromitowany tylko dlatego, że usłyszało się o „incydencie bezpieczeństwa portfela”, a tym bardziej nie należy pochopnie przenosić aktywów na nieznane adresy z powodu tak zwanych pilnych powiadomień o bezpieczeństwie.
W końcu w wielu przypadkach atakujący naprawdę liczą nie na przełamanie najsilniejszej technicznej linii obrony, lecz na to, że użytkownicy dobrowolnie wykonają ostatni krok w panice (Dalsza lektura: „Czy AI „rzuca wyzwanie” kryptografii? Web3 musi przygotować się na deszczowe dni, ale nigdy nie może spieszyć się z migracją”).
Końcowe przemyślenia
W przeszłości zdanie najczęściej podkreślane w branży Crypto brzmiało: „Not your keys, not your coins”.
To zdanie jest nadal ważne, ponieważ kontrola nad kluczem prywatnym decyduje o tym, czy użytkownicy mogą naprawdę niezależnie kontrolować swoje aktywa.
Jednak wraz z stopniowym dojrzewaniem portfeli, giełd i produktów finansowych on-chain musimy również zdać sobie sprawę, że ochrona klucza prywatnego jest tylko częścią całego systemu bezpieczeństwa.
Prawdziwy portfel sprzętowy może nadal zostać fizycznie zmodyfikowany podczas dostawy; powiadomienie rzeczywiście wysłane z oficjalnego systemu e-mail może również zostać wykorzystane przez atakujących; a zestaw narzędzi stron trzecich pierwotnie służących do wzmocnienia bezpieczeństwa może nawet stać się wejściem do podstawowego systemu funduszy.
Te przypadki nie oznaczają, że powinniśmy stracić zaufanie do wszystkich portfeli i usług zewnętrznych. Wręcz przeciwnie, przypominają całej branży, że bezpieczeństwo należy rozszerzyć z wnętrza pojedynczego produktu na cały proces łańcucha dostaw, zarządzania uprawnieniami, komunikacji z użytkownikiem i reagowania kryzysowego.
W końcu prawdziwie dojrzały system bezpieczeństwa Crypto musi nie tylko zapewniać, że klucze prywatne nie są łatwo ujawniane, ale także w miarę możliwości zapewnić, że nawet jeśli jakieś zewnętrzne ogniwo zawiedzie, cały mechanizm nadal może stanowczo zatrzymać ryzyko w połowie drogi i zapobiec jego przekroczeniu ostatecznej czerwonej linii chroniącej aktywa użytkowników.
