Ten artykuł został nadesłany przez członków społeczności. Autorem jest Minzhi He, audytor w CertiK.
Poglądy zawarte w tym artykule są poglądami autora/współautora i nie muszą odzwierciedlać poglądów Akademii Binance.
TL;DR
Mosty Blockchain są krytyczne dla osiągnięcia interoperacyjności w przestrzeni blockchain. Stąd bezpieczeństwo mostu ma ogromne znaczenie. Niektóre powszechne luki w zabezpieczeniach mostów obejmują słabą walidację on-chain i off-chain, niewłaściwą obsługę natywnych tokenów i błędną konfigurację. Testowanie mostu przeciwko wszystkim możliwym wektorom ataku, jest zalecane w celu zapewnienia solidnej logiki weryfikacji.
Wprowadzenie
Most blockchain to protokół łączący dwa blockchainy, w celu umożliwienia interakcji między nimi. Jeśli posiadasz bitcoina, ale chcesz uczestniczyć w aktywności DeFi w sieci Ethereum, most blockchain pozwala zrobić to, bez sprzedawania swojego bitcoina.
Mosty Blockchaina są fundamentalne dla osiągnięcia interoperacyjności w przestrzeni blockchaina. Funkcjonują one przy użyciu różnych walidacji on-chain i off-chain, a zatem mają różne luki w zabezpieczeniach.
Dlaczego Bezpieczeństwo Mostu Jest Krytycznie Ważne?
Most zazwyczaj przechowuje token, który użytkownik chce przenieść z jednego łańcucha do drugiego. Często wdrażane jako smart kontrakty, mosty trzymają znaczną ilość tokenów w miarę gromadzenia się transferów cross-chain, co czyni je lukratywnymi celami dla hakerów.
Ponadto, mosty blockchain mają dużą powierzchnię możliwego ataku, ponieważ obejmują wiele komponentów. Mając to na uwadze, oszuści są wysoce zmotywowani, aby obrać za cel aplikacje typu cross-chain, w celu wyprowadzenia dużych sum pieniędzy.
Ataki na mosty doprowadziły w 2022 roku do strat w wysokości ponad 1,3 mld USD, stanowiąc 36% wszystkich strat w tym roku - wynika z szacunków CertiK.
Typowe Luki w Zabezpieczeniach Mostów
Aby zwiększyć bezpieczeństwo mostów, warto zrozumieć typowe luki w zabezpieczeniach mostów i przetestować je pod tym kątem, przed uruchomieniem. Te luki w zabezpieczeniach można podzielić na następujące cztery obszary.
Słaba walidacja on-chain
W przypadku prostych mostów, zwłaszcza tych zaprojektowanych dla konkretnych DApps, walidacja on-chain jest ograniczona do minimum. Mosty te polegają na scentralizowanym zapleczu w celu wykonania podstawowych operacji, takich jak mintowanie, wypalanie i transfery tokenów, podczas gdy wszystkie weryfikacje są wykonywane off-chain.
W przeciwieństwie do tego, inne rodzaje mostów używają smart kontraktów do walidowania wiadomości i wykonywania weryfikacji on-chain. W tym scenariuszu, gdy użytkownik wpłaca środki do łańcucha, smart kontrakt generuje podpisaną wiadomość i zwraca podpis w transakcji. Podpis ten służy jako dowód wpłaty i jest używany do weryfikacji żądania wypłaty przez użytkownika na drugim łańcuchu. Proces ten powinien być w stanie zapobiec różnym atakom przeciwko bezpieczeństwu, w tym atakom typu replay i fałszowaniu zapisów depozytowych.
Jeśli jednak istnieje luka w trakcie procesu walidacji on-chain, atakujący może wyrządzić poważne szkody. Na przykład, jeśli most używa drzewa Merkle do walidacji rekordu transakcji, atakujący może wygenerować sfałszowane dowody. Oznacza to, że mogą oni ominąć walidację dowodu i mintować nowe tokeny na swoje konto, jeśli proces walidacji jest wrażliwy.
Niektóre mosty implementują koncepcję "wrappowanych tokenów." Na przykład, gdy użytkownik przekazuje DAI z Ethereum do BNB Chain, jego DAI jest pobierane z kontraktu Ethereum, a równoważna ilość wrappowanego DAI jest emitowana na BNB Chain.
Jednakże, jeśli ta transakcja nie jest prawidłowo zatwierdzona, atakujący mógłby wdrożyć złośliwy kontrakt, aby skierować wrappowane tokeny z mostu na nieprawidłowy adres, poprzez manipulację funkcją.
Atakujący potrzebują również ofiar do zatwierdzenia kontraktu mostowego, aby przenieść tokeny za pomocą funkcji "transferFrom",w celu wyciągnięcia aktywów z kontraktu mostowego.
Niestety, jest gorzej, ponieważ wiele mostów żąda nieskończonej akceptacji tokenów od użytkowników DApp. Jest to powszechna praktyka, która obniża opłaty gas, ale stwarza dodatkowe ryzyka, umożliwiając smart kontraktowi dostęp do nieograniczonej liczby tokenów z portfela użytkownika. Atakujący są w stanie wykorzystać brak walidacji i nadmierną akceptację, aby przenieść tokeny od innych użytkowników do siebie.
Słaba walidacja off-chain
W niektórych systemach mostowych, serwer zaplecza off-chain odgrywa krytyczną rolę w weryfikacji zasadności wiadomości wysyłanych z blockchaina. W tym przypadku, skupiamy się na weryfikacji transakcji depozytowych.
Most blockchain z walidacją off-chain, działa w następujący sposób:
Użytkownicy wchodzą w interakcję z DApp, aby zdeponować tokeny do smart kontraktu na łańcuchu źródłowym.
DApp następnie wysyła hash transakcji depozytowej do serwera zaplecza, poprzez API.
Hash transakcji podlega kilku walidacjom przez serwer. Jeśli zostanie uznany za uzasadniony, podpisujący potwierdza wiadomość i wysyła podpis z powrotem do interfejsu użytkownika poprzez API.
Po otrzymaniu podpisu, DApp weryfikuje go i pozwala użytkownikowi na wycofanie swoich tokenów z łańcucha docelowego.
Serwer backend musi zapewnić, że transakcja depozytowa, którą przetwarza, rzeczywiście miała miejsce i nie została sfałszowana. Taki serwer zaplecza określa, czy użytkownik może wypłacić tokeny na łańcuchu docelowym i dlatego jest celem o wysokiej wartości dla atakujących.
Serwer backend musi zatwierdzić strukturę emitowanego zdarzenia transakcji, a także adres kontraktu, który emitował zdarzenie. Jeśli to ostatnie zostanie zaniedbane, atakujący mógłby wdrożyć złośliwy kontrakt, aby sfałszować zdarzenie depozytowe o takiej samej strukturze, jak legalne zdarzenie depozytowe.
Jeśli serwer backend nie zweryfikuje, który adres wyemitował zdarzenie, uzna to za ważną transakcję i podpisze wiadomość. Atakujący mógłby następnie wysłać hash transakcji do zaplecza, omijając weryfikację i umożliwiając mu wycofanie tokenów z łańcucha docelowego.
Nieprawidłowa obsługa tokenów natywnych
Mosty przyjmują różne podejścia do obsługi tokenów natywnych i tokenów użytkowych. Na przykład, w sieci Ethereum natywnym tokenem jest ETH a większość tokenów użytkowych przestrzega standardu ERC-20.
Kiedy użytkownik zamierza przenieść swoje ETH do innego łańcucha, musi najpierw zdeponować je do kontraktu mostowego. Aby to osiągnąć, użytkownik po prostu dołącza ETH do transakcji, a ilość ETH można pobrać, czytając pole "msg.value" transakcji.
Deponowanie tokenów ERC-20 różni się znacząco od deponowania ETH. Aby zdeponować token ERC-20, użytkownik musi najpierw zezwolić na wydanie swoich tokenów w kontrakcie mostowym. Po zatwierdzeniu i zdeponowaniu tokenów do kontraktu pomostowego, kontrakt wypali tokeny użytkownika za pomocą funkcji "burnFrom()" lub przekaże token użytkownika do kontraktu, za pomocą funkcji "transferFrom()".
Jednym z podejść do różnicowania tego, jest użycie instrukcji if-else w ramach tej samej funkcji. Innym podejściem jest stworzenie dwóch oddzielnych funkcji do obsługi każdego scenariusza. Próba zdeponowania ETH za pomocą funkcji depozytu ERC-20, może spowodować utratę tych środków.
Podczas obsługi żądań depozytu ERC-20, użytkownicy zazwyczaj podają adres tokena jako wejście do funkcji depozytu. Stanowi to istotne zagrożenie, ponieważ podczas transakcji mogą pojawić się niezaufane połączenia zewnętrzne. Wdrożenie whitelisty, która obejmuje tylko tokeny obsługiwane przez most, jest powszechną praktyką w celu zminimalizowania ryzyka. Tylko adresy z whitelisty mogą być przekazywane jako argumenty. Zapobiega to zewnętrznym połączeniom, ponieważ zespół projektowy ma już przefiltrowany adres tokena.
Jednak problemy mogą również pojawić się, gdy mosty obsługują transfer cross-chain tokena natywnego, ponieważ token natywny nie ma adresu. Adres zerowy (0x000...0) jest reprezentatywny dla tokena natywnego. Może to być problematyczne, ponieważ przekazanie zerowego adresu do funkcji może ominąć weryfikację whitelisty, nawet jeśli zostanie wdrożone nieprawidłowo.
Kiedy kontrakt mostowy wywołuje "transferFrom", aby przenieść aktywa użytkownika do kontraktu, zewnętrzne wywołanie adresu zerowego wraca błędne, ponieważ nie ma funkcji "transferFrom" zaimplementowanej w adresie zerowym. Jednak transakcja może nadal występować, jeśli kontrakt nie obsługuje prawidłowo wartości zwrotnej. Stwarza to możliwość wykonania transakcji przez atakujących, bez przekazania jakichkolwiek tokenów do kontraktu.
Błędna Konfiguracja
W większości mostów blockchain, ich uprzywilejowaną rolą jest odpowiedzialność za wprowadzanie tokenów i adresów na whitelistę lub czarną listę, przypisywanie lub zmianę sygnatariuszy i inne krytyczne konfiguracje. Upewnienie się, że wszystkie konfiguracje są dokładne jest kluczowe, ponieważ nawet pozornie błahe przeoczenia mogą prowadzić do znacznych strat.
W rzeczywistości doszło do incydentu, w którym atakujący ominął z powodzeniem weryfikację rekordu transferu, ze względu na błędną konfigurację. Zespół projektowy na kilka dni przed włamaniem wdrożył aktualizację protokołu, która polegała na zmianie pewnej zmiennej. Zmienna została użyta do reprezentowania domyślnej wartości zaufanej wiadomości. Zmiana ta powodowała, że wszystkie wiadomości były automatycznie uznawane za sprawdzone, co pozwalało atakującemu na przesłanie arbitralnej wiadomości i przejście procesu weryfikacji.
Jak Zwiększyć Bezpieczeństwo Mostów
Cztery powszechne luki w zabezpieczeniach mostów wyjaśnione powyżej, pokazują wyzwania związane z zapewnieniem bezpieczeństwa w połączonym ekosystemie blockchain. W przypadku każdej z tych podatności, należy wziąć pod uwagę wiele czynników i nie można zastosować jednego podręcznika do wszystkich z nich.
Na przykład, dostarczenie ogólnych wytycznych w celu zapewnienia bezbłędnego procesu weryfikacji stanowi wyzwanie, ponieważ każdy most ma unikalne wymagania dotyczące weryfikacji. Najbardziej skutecznym podejściem do zapobiegania obejściu weryfikacji jest dokładne przetestowanie mostu przeciwko wszystkim możliwym wektorom ataku i zapewnienie, że logika weryfikacji jest solidna.
Podsumowując, należy przeprowadzić rygorystyczne testy przed potencjalnymi atakami i zwrócić szczególną uwagę na najczęściej występujące luki bezpieczeństwa w mostach.
Przemyślenia Końcowe
Ze względu na swoją wysoką wartość, mosty cross-chain od dawna są celem dla atakujących. Budujący mogą wzmocnić bezpieczeństwo swoich mostów, przeprowadzając dokładne testy przed wdrożeniem i angażując się w audyty stron zewnętrznych, zmniejszając ryzyko niszczących włamań, które nękały mosty w ciągu ostatnich kilku lat. Mosty są krytyczne w świecie wielu łańcuchów, ale bezpieczeństwo musi być głównym priorytetem, podczas projektowania i budowania efektywnej infrastruktury Web3.
Dalsza Lektura
Czym Jest Interoperacyjność Międzyłańcuchowa?
Trzy Popularne Mosty Krypto i Sposób Ich Działania
Wyłączenie Odpowiedzialności i Ostrzeżenie o Ryzyku: Niniejsza treść jest prezentowana w stanie takim jakim jest, wyłącznie w celach ogólnoinformacyjnych i edukacyjnych, bez jakichkolwiek gwarancji. Nie należy jej interpretować jako porady finansowej, prawnej ani innej porady specjalistycznej i nie ma ona również charakteru zachęty do zakupu jakiegokolwiek konkretnego produktu lub usługi. Powinieneś(-aś) zasięgnąć własnej porady u odpowiednich zawodowych doradców. Jeżeli artykuł jest napisany przez osobę z zewnątrz, należy pamiętać, że wyrażone poglądy są poglądami tej osoby i nie muszą odzwierciedlać poglądów Akademii Binance. Więcej informacji można znaleźć w naszym pełnym wyłączeniu odpowiedzialności tutaj. Ceny aktywów cyfrowych mogą być zmienne. Wartość Twojej inwestycji może spaść lub wzrosnąć i możesz nie odzyskać zainwestowanej kwoty. Ponosisz wyłączną odpowiedzialność za swoje decyzje inwestycyjne, a Akademia Binance nie ponosi odpowiedzialności za jakiekolwiek straty, jakie możesz ponieść. To nie jest porada z zakresu finansów, prawa ani innej dziedziny. Aby uzyskać więcej informacji, zapoznaj się z naszymi Warunkami Użytkowania i Ostrzeżeniem o Ryzyku.