Nie tylko klucz prywatny: jak chronić bezpieczeństwo Web3 od portfela, L2 do łańcucha dostaw?

Gdy ryzyko bezpieczeństwa rozprzestrzenia się z jednego punktu na łańcuch, obrona użytkowników musi ewoluować z ochrony klucza prywatnego do kompleksowego zestawu nawyków.

Autor: imToken

W czerwcu, świat kryptowalut przeszedł przez serię incydentów bezpieczeństwa, które objęły wiele aspektów.

Najnowszy miesięczny raport bezpieczeństwa od PeckShield pokazuje, że w czerwcu miało miejsce 40 poważnych ataków hakerskich, a całkowite straty wyniosły aż 75,87 miliona dolarów. Co więcej, te ataki nie były skoncentrowane na jednym rodzaju ścieżki ataku, ale obejmowały luki w realizacji podpisów portfeli, luki w protokołach L2 oraz ataki na łańcuch dostaw usług stron trzecich, co doprowadziło do utraty wielu linii obrony w tym samym miesiącu.

Gdy ryzyko bezpieczeństwa Web3 rozprzestrzenia się z jednego punktu dostępu na całą ścieżkę interakcji w łańcuchu, każdy użytkownik musi na nowo przemyśleć jedno pytanie: czy moje aktywa Crypto są nadal bezpieczne?

I. Znaczenie realizacji podpisów na poziomie portfela poza kluczem prywatnym

Incydent bezpieczeństwa, który miał miejsce w portfelu SecondFi w ekosystemie Cardano, jest najbardziej wymownym przykładem.

SecondFi jest następcą portfela Yoroi w ekosystemie Cardano. W dniach od 21 do 23 czerwca, hakerzy przetransferowali około 16 milionów ADA z adresów niektórych użytkowników SecondFi, co dotyczyło około 374 portfeli, a według cen w dniu zdarzenia, straty wyniosły około 2,4 miliona dolarów. SecondFi później ogłosił, że podjął pilne środki, aby dodatkowo zabezpieczyć około 129 milionów ADA, które mogły być zagrożone.

Najbardziej niezwykłym aspektem tego incydentu jest to, że dotknięci użytkownicy nie przekazali aktywnie swojego frazy odzyskiwania hakerom; problem leżał w realizacji podpisów na poziomie portfela. Zgodnie z analizą agencji bezpieczeństwa BlockSec, błędnie wyprowadzono nonce podpisu z publicznych wiadomości transakcyjnych, pomijając wymagany przez standardy prefix tajnego nonce.

To sprawiło, że za każdym razem, gdy użytkownicy korzystali z dotkniętej wersji portfela do podpisywania transakcji, publiczne dane podpisu publikowane na łańcuchu ujawniały informacje wystarczające do wyprowadzenia klucza prywatnego adresu, dlatego hakerzy nie musieli włamywać się do telefonów użytkowników ani zdobywać frazy odzyskiwania; wystarczyło analizować publiczne dane na łańcuchu, aby móc odzyskać klucz prywatny podpisu odpowiadającego adresowi.

Z perspektywy użytkownika, portfel nadal działał normalnie, ponieważ fraza odzyskiwania nie została ujawniona w oknie pop-up, hasło nie zostało złamane, a transakcje rzeczywiście zostały zainicjowane przez użytkownika. Jednak z perspektywy kryptografii, tak długo jak adres użytkownika wygenerował jakieś ważne podpisy za pomocą dotkniętej wersji, publiczne dane transakcji i podpisów mogły pomóc hakerom w wyprowadzeniu klucza prywatnego podpisu tego adresu.

Ostatecznie bezpieczeństwo portfela zależy od tego, czy klucz prywatny jest poprawnie generowany, czy podpisy są realizowane zgodnie z rygorystycznymi standardami kryptograficznymi oraz czy te kluczowe kody mogą być zewnętrznie audytowane i weryfikowane, co podkreśla znaczenie otwartego źródła dla kluczowych komponentów portfela.

Oczywiście, to jest specyficzna wada implementacji konkretnego portfela, a nie ogólny problem wszystkich portfeli zarządzanych przez użytkowników. Na przykład, kod źródłowy TokenCore od imToken jest publicznie hostowany na GitHubie, obejmując zarządzanie kluczami, pochodzenie adresów i podstawowe funkcje podpisywania transakcji.

Choć otwarte źródło nie oznacza, że kod jest wolny od luk, ani że użytkownicy mogą całkowicie zrezygnować z czujności, to w przypadku najbardziej wrażliwych komponentów kryptograficznych i podpisów, otwarte źródło przynajmniej zapewnia ważny warunek, że badacze bezpieczeństwa, deweloperzy i społeczność mogą sprawdzić kod, odtworzyć problemy i prowadzić ciągłe testy, zamiast polegać na nieweryfikowalnej czarnej skrzynce.

Dla zwykłych użytkowników, takie incydenty odpowiadają kilku bardziej realistycznym zasadom bezpieczeństwa.

• Po pierwsze, portfel powinien być zawsze pobierany z oficjalnej strony internetowej lub oficjalnego sklepu z aplikacjami i regularnie aktualizowany do wersji zabezpieczających;
• Po drugie, nie należy przechowywać wszystkich aktywów w tym samym portfelu do codziennych interakcji; duże, długoterminowe aktywa mogą być przechowywane w portfelach sprzętowych lub niezależnych zimnych portfelach, oddzielając je od gorącego portfela, który często łączy się z DApp.
• Co ważniejsze, gdy oficjalny portfel potwierdzi, że wystąpiła luka w generowaniu kluczy lub realizacji podpisów, samo importowanie starej frazy odzyskiwania do innego portfela zazwyczaj nie rozwiązuje problemu;

Ponieważ importując tę samą grupę fraz odzyskiwania do innych portfeli, oryginalnie już ujawnione adresy i klucze prywatne nie zmienią się. Dotknięte aktywa muszą zostać przeniesione do nowego adresu, który nigdy nie był podpisywany przez lukę; dla zwykłych użytkowników, bardziej rozsądne podejście zazwyczaj polega na ponownym utworzeniu całkowicie nowego portfela i frazy odzyskiwania zgodnie z oficjalnym procesem awaryjnym, a następnie przeniesieniu aktywów, zamiast wielokrotnego importowania lub operowania na oryginalnym adresie.

II. L2 to nie tylko „tańszy Ethereum”, ale także złożony łańcuch zaufania

Oprócz portfela, wiele incydentów w czerwcu wskazało na rosnące ryzyko w coraz bardziej złożonych systemach L2.

14 i 18 czerwca, dwa związane z Aztec starsze wdrożenia Rollup zostały zaatakowane, a całkowite straty wyniosły około 4,35 miliona dolarów.

Należy szczególnie zaznaczyć, że zaatakowane zostały starsze wdrożenia, takie jak Aztec Connect, które są już w stanie spadku, co nie oznacza, że aktualna sieć Aztec Network została zaatakowana, ale problemy ujawnione w tych dwóch incydentach mają istotne znaczenie ostrzegawcze dla całej dziedziny ZK Rollup.

W jednym z tych incydentów, hakerzy wykorzystali niezgodność między liczbą transakcji a rzeczywistymi przetwarzanymi danymi, co spowodowało, że system udowodnił wewnętrzne zapisanie depozytu, omijając proces odjęcia salda na L1.

Inny incydent wynikał z braku ograniczeń w obwodzie dowodu zero-knowledge, gdzie system zweryfikował formalnie ważny dowód, ale nie zapewnił, że używana przez ten dowód prywatna struktura stanu była całkowicie zgodna z publicznym korzeniem stanu używanym do rozliczeń na Ethereum, co pozwoliło hakerom na generowanie dowodu wokół fałszywej struktury stanu i wyciąganie aktywów z umowy L1.

Takie problemy trudno ująć w tradycyjnym rozumieniu „czy umowa zawiera jakąś lukę w kodzie”. W końcu dowód zero-knowledge może udowodnić, że dany proces obliczeniowy spełnia ustalone zasady, ale pod warunkiem, że zasady te są poprawne i kompletne; jeśli deweloper zapomni o ograniczeniu kluczowej zmiennej, dowód może być matematycznie ważny, ale udowodni coś, co nie jest zgodne z rzeczywistym stanem rozliczenia.

Incydent bezpieczeństwa, który później wystąpił w Taiko, ujawnił inny rodzaj ryzyka łańcucha zaufania L2.

22 czerwca, proces weryfikacji dowodów oparty na SGX w Taiko został wykorzystany, co spowodowało straty w wysokości około 1,7 miliona dolarów. Zgodnie z analizą BlockSec, hakerzy użyli klucza prywatnego do podpisywania SGX enclave, który wcześniej został przesłany do publicznego repozytorium GitHub, a także wykorzystali lukę w umowie weryfikacyjnej na łańcuchu, która nie odrzuciła trybu DEBUG Enclave, rejestrując złośliwego dowodzącego jako legalny instancję.

Hakerzy następnie sfałszowali dowód stanu L2, co pozwoliło umowie na Ethereum zaakceptować nieistniejący stan L2, a ostatecznie wyciągnęli aktywa z funduszy mostu, ponieważ klucz używany do podpisywania zaufanego środowiska wykonawczego został ujawniony, a zasady zdalnej weryfikacji nie sprawdziły właściwości środowiska uruchomieniowego, co ostatecznie sprawiło, że „zweryfikowany” dowód stracił swoje pierwotne zaufane znaczenie.

W międzyczasie, Base doświadczył w dniach 25-26 czerwca przerwy w produkcji bloków w sieci głównej. Po analizie Base stwierdził, że obie przerwy wynikały z tej samej wady logiki budowy bloków: jedna nieudana transakcja nie oczyściła poprawnie wcześniej zapisanych stanów, co spowodowało błędne obliczenie gazu dla kolejnych transakcji i wygenerowanie bloków zawierających nieprawidłowe przejścia stanu. Ponieważ inne węzły nie mogły zaakceptować tego bloku, sieć ostatecznie przestała się rozwijać. Base stwierdził, że integralność łańcucha nie została naruszona w trakcie incydentu, a fundusze użytkowników były zawsze bezpieczne.

To nie był przypadek kradzieży aktywów ani ataku zewnętrznego, ale techniczna awaria wpływająca na dostępność i zdolność do przywrócenia sieci. Jednak z szerszej perspektywy bezpieczeństwa, dostępność sama w sobie jest częścią modelu bezpieczeństwa L2.

Ponieważ dla użytkowników, czy łańcuch jest bezpieczny, nie zależy tylko od tego, czy hakerzy mogą sfałszować aktywa, ale także od tego, czy bloki mogą być ciągle produkowane, mosty między łańcuchami mogą działać prawidłowo, węzły mogą szybko się odbudować, a w przypadku awarii systemu, użytkownicy nadal mają wykonalne ścieżki wyjścia.

Dlatego użytkownicy korzystający z L2 nie powinni porównywać tylko opłat transakcyjnych i oczekiwań airdropów. W przypadku mniejszych, nowo uruchomionych lub szybko zmieniających się mechanizmów bezpieczeństwa L2, należy unikać długoterminowego przechowywania dużych aktywów, które przekraczają rzeczywiste potrzeby użytkowania; przed przejściem między łańcuchami należy upewnić się, że używa się oficjalnego mostu oraz zrozumieć czas wypłaty, mechanizmy wstrzymania i metody awaryjnego wyjścia; w przypadku zatrzymania produkcji bloków w sieci, anomalii między łańcuchami lub oficjalnych ostrzeżeń o bezpieczeństwie, nie należy wielokrotnie składać transakcji ani kontynuować mostowania aktywów.

Bardziej rozsądne podejście polega na rozdzieleniu zarządzania aktywami o różnych zastosowaniach i poziomach ryzyka, a nie trzymaniu całej płynności w jednym L2, jednym moście między łańcuchami lub jednej metodzie wyjścia.

III. Umowa nie została złamana, ale usługi stron trzecich mogą przynieść atak użytkownikom

Jeśli problemy z portfelami i L2 występują w stosunkowo podstawowych komponentach technologicznych, to incydent Polymarket pokazuje, że najbliższy użytkownikowi interfejs internetowy również może stać się punktem dostępu do funduszy.

25 czerwca Polymarket ogłosił, że jeden z jego dostawców zewnętrznych został zaatakowany, a hakerzy wykorzystali to do wstrzyknięcia złośliwego skryptu do interfejsu Polymarket, do którego uzyskało dostęp część użytkowników.

Zgodnie z danymi z agencji bezpieczeństwa i analityków łańcuchowych, incydent spowodował straty użytkowników w wysokości około 3 milionów dolarów, dotyczących około 11 portfeli. Skradzione fundusze następnie przeszły z Polygon do Ethereum i zostały wymienione na około 1893 ETH, jednak Polymarket później ogłosił, że usunął dotknięte zależności i zwróci pełną kwotę poszkodowanym użytkownikom.

Kluczowym aspektem tego incydentu jest to, że użytkownicy mogli nadal odwiedzać poprawną domenę Polymarket, a obecne ujawnienia nie wskazują na lukę w podstawowej inteligentnej umowie Polymarket; problem leży głównie w zależnościach front-endowych ładowanych przez stronę internetową.

To także lustro, ponieważ większość aplikacji Web3 nie działa całkowicie na łańcuchu; użytkownicy widzą strony internetowe, takie jak interfejsy transakcyjne, które wciąż w dużej mierze polegają na tradycyjnej infrastrukturze internetowej i zewnętrznych pakietach oprogramowania, a każde z tych zależności, które zostaną zaatakowane, mogą spowodować, że legalna strona wyświetli błędne informacje, zmieni adres odbiorcy lub skłoni portfel do podpisania złośliwej transakcji.

Dlatego „adres URL jest prawdziwy” nie oznacza automatycznie, że „wszystkie kody ładowane w tym momencie są bezpieczne”, a „umowa przeszła audyt” nie oznacza, że cała ścieżka interakcji między użytkownikiem a umową jest wolna od ryzyka. W obliczu takich ataków front-endowych i łańcucha dostaw, zwykli użytkownicy mają trudności z samodzielnym sprawdzeniem każdego fragmentu kodu ładowanego na stronie, ale nadal mogą ograniczyć potencjalne straty poprzez zmniejszenie uprawnień do pojedynczej interakcji:

• Używaj niezależnego portfela do interakcji z DApp: portfel do długoterminowego oszczędzania nie powinien być bezpośrednio łączony z różnymi stronami DeFi, NFT, rynkami prognoz i airdropami; portfel do codziennych interakcji powinien przechowywać tylko fundusze, które są gotowe do użycia w najbliższym czasie, co ogranicza zakres wpływu, nawet jeśli wystąpią problemy z front-endem lub autoryzacją;
• Zwracaj uwagę na rzeczywiste operacje przed podpisaniem, a nie tylko na przyciski na stronie: to, co na stronie mówi „zaloguj się”, „odbierz” lub „potwierdź zamówienie”, niekoniecznie oznacza, że podpis w portfelu dotyczy tej samej czynności;
• W przypadku nieprawidłowości na stronie, nie polegaj na nawyku kontynuowania operacji: jeśli strona nagle wymaga ponownego importu frazy odzyskiwania, pobrania dodatkowych wtyczek lub wyświetla transakcje, które nie są zgodne z opisem na stronie, należy wstrzymać interakcję, potwierdzić sytuację przez różne oficjalne kanały projektu oraz sprawdzić lub cofnąć nieużywane wcześniej autoryzacje;

Z perspektywy produktów portfelowych, oznacza to również, że rola portfela ulega zmianie.

Nie powinien być tylko narzędziem do przechowywania kluczy prywatnych i wyświetlania okienek podpisów, ale także powinien jak najlepiej pomagać użytkownikom w zrozumieniu intencji transakcji, identyfikacji nietypowych autoryzacji, prezentacji zmian aktywów oraz dostarczaniu wystarczająco jasnych ostrzeżeń przed wystąpieniem wysokiego ryzyka interakcji.

Jednak portfel nie może całkowicie wyeliminować ryzyka dla użytkowników. Bardziej realistyczny model bezpieczeństwa polega na wspólnym zmniejszaniu powierzchni ataku przez portfel, protokoły, L2, dostawców usług stron trzecich i użytkowników, a nie na przerzucaniu całej odpowiedzialności na którąkolwiek ze stron.

Na koniec

W przeszłości często mówiono, że kto posiada klucz prywatny, ten posiada aktywa na łańcuchu.

To zdanie wciąż jest prawdziwe, ale nie obejmuje całego procesu, przez który przechodzą aktywa użytkowników od „generowania intencji transakcji” do „ukończenia rozliczenia na łańcuchu”. Dzisiejsze bezpieczeństwo Web3 to już nie tylko ochrona grupy fraz odzyskiwania, ale ochrona całej ścieżki od generowania kluczy przez portfel, wyświetlanie transakcji, realizację podpisów, po weryfikację sieci i ostateczne rozliczenie.

Oczywiście, to nie oznacza, że użytkownicy powinni unikać wszelkich interakcji na łańcuchu. Dla użytkowników, naprawdę skuteczne nawyki bezpieczeństwa oznaczają, że muszą oddzielić zarządzanie aktywami według ich przeznaczenia, poziomu ryzyka i scenariuszy interakcji: długoterminowe aktywa w wysokiej izolacji, codzienne interakcje z małymi kwotami, niskie uprawnienia dla nieznanych DApp, wielokrotne weryfikacje w przypadku operacji wysokiego ryzyka.

W końcu, gdy ryzyko bezpieczeństwa rozprzestrzenia się z jednego punktu na łańcuch, obrona użytkowników musi ewoluować z ochrony klucza prywatnego do kompleksowego zestawu nawyków.

Wspólnie dążmy do lepszych praktyk.