Ten artykuł jest wkładem społeczności. Autorem jest Minzhi He, audytor CertiK.
Opinie zawarte w tym artykule są opiniami współautora/autora i niekoniecznie odzwierciedlają poglądy Binance Academy.
Streszczenie
Mosty Blockchain mają kluczowe znaczenie dla osiągnięcia interoperacyjności w przestrzeni blockchain. Dlatego Twoje bezpieczeństwo jest sprawą najwyższej wagi. Niektóre z najczęstszych luk w zabezpieczeniach mostów obejmują słabą weryfikację w łańcuchu i poza łańcuchem, niewłaściwą obsługę tokenów natywnych i błędne konfiguracje. Zaleca się przetestowanie mostu pod kątem wszystkich możliwych wektorów ataku, aby zapewnić solidną logikę weryfikacji.
Wstęp
Most blockchain to protokół łączący dwa łańcuchy bloków, aby umożliwić interakcje między nimi. Jeśli masz Bitcoin, ale chcesz uczestniczyć w aktywności DeFi w sieci Ethereum, most blockchain pozwala to zrobić bez konieczności sprzedaży Bitcoinów.
Mosty Blockchain mają kluczowe znaczenie dla osiągnięcia interoperacyjności w przestrzeni blockchain. Przechodzą przez różne weryfikacje w łańcuchu i poza łańcuchem, dlatego przedstawiają różne luki w zabezpieczeniach.
Dlaczego bezpieczeństwo mostów jest istotne?
Zazwyczaj most przechowuje token, który użytkownik chce przenieść z jednego łańcucha do drugiego. Mosty, często wdrażane w formie inteligentnych kontraktów, przechowują znaczną liczbę tokenów w miarę kumulacji transferów między łańcuchami, co czyni je lukratywnymi celami dla hakerów.
Ponadto mosty blockchain mają dużą powierzchnię ataku, ponieważ zawierają wiele komponentów. Mając to na uwadze, szkodliwi przestępcy uważają aplikacje międzyłańcuchowe za bardzo dobry cel kradzieży dużych ilości środków.
Według szacunków CertiK w 2022 r. ataki na mosty wygenerowały straty o wartości ponad 1,3 miliarda dolarów, co stanowi 36% całkowitych strat za ten rok.
Typowe luki w zabezpieczeniach mostu
Aby poprawić bezpieczeństwo mostów, warto poznać ich najczęstsze podatności i przetestować je przed ich udostępnieniem. Luki te można podzielić na cztery następujące obszary.
Słaba weryfikacja w łańcuchu
W przypadku prostych mostów, szczególnie tych zaprojektowanych dla określonych aplikacji DApp, weryfikacja w łańcuchu jest ograniczona do minimum. Mosty te opierają się na scentralizowanym backendie do wykonywania podstawowych operacji, takich jak bicie, spalanie i przesyłanie tokenów, podczas gdy wszystkie weryfikacje są przeprowadzane poza łańcuchem.
Natomiast inne typy mostów wykorzystują inteligentne kontrakty do sprawdzania wiadomości i przeprowadzania weryfikacji w łańcuchu. W takich przypadkach, gdy użytkownik dokonuje depozytu w łańcuchu, inteligentny kontrakt generuje podpisaną wiadomość i zwraca podpis w transakcji. Podpis służy jako dowód wpłaty i służy do weryfikacji żądania wypłaty użytkownika w drugim łańcuchu. Proces ten powinien umożliwiać zapobieganie różnym rodzajom ataków na bezpieczeństwo, w tym atakom polegającym na powtarzaniu i fałszowaniu zapisów depozytów.
Jeśli jednak w procesie sprawdzania poprawności w łańcuchu występuje luka, osoba atakująca może wyrządzić ogromne szkody. Na przykład, jeśli most wykorzystuje drzewo Merkle do sprawdzenia dziennika transakcji, osoba atakująca może wygenerować sfałszowane rachunki. Oznacza to, że jeśli proces weryfikacji jest podatny na ataki, osoba atakująca może ominąć weryfikację paragonu i wygenerować nowe tokeny dla Twojego konta.
Niektóre mosty realizują koncepcję „opakowanych tokenów”. Na przykład, gdy użytkownik przesyła DAI z Ethereum do BNB Chain, DAI jest pobierane z kontraktu Ethereum i równoważna ilość zapakowanego DAI jest wydawana w BNB Chain.
Jeśli jednak transakcja nie zostanie poprawnie zweryfikowana, osoba atakująca może wdrożyć złośliwą umowę, aby skierować opakowane tokeny z mostu na nieprawidłowy adres.
Atakujący potrzebują również, aby ofiary zatwierdziły umowę pomostową, aby przesłać tokeny za pomocą funkcji „transferFrom”, a tym samym wyczerpać zasoby z umowy pomostowej.
Niestety sytuacja jest gorsza, ponieważ wiele mostów żąda nieskończonej akceptacji tokenów od użytkowników DApps. Jest to powszechna praktyka, która obniża opłaty za gaz, ale stwarza dodatkowe ryzyko, umożliwiając inteligentnej umowie dostęp do nieograniczonej liczby tokenów z portfela użytkownika. Atakujący mogą wykorzystać brak weryfikacji i nadmierną zgodę do przesyłania tokenów od innych użytkowników do siebie.
Słaba walidacja poza łańcuchem
W niektórych systemach mostowych serwer zaplecza poza łańcuchem odgrywa kluczową rolę w weryfikacji legalności wiadomości wysyłanych z łańcucha bloków. Tym razem skupimy się na weryfikacji transakcji depozytowych.
Most blockchain z walidacją poza łańcuchem działa w następujący sposób:
Użytkownicy wchodzą w interakcję z DApp, aby deponować tokeny w inteligentnej umowie łańcucha źródłowego.
Następnie DApp wysyła skrót transakcji depozytowej do serwera zaplecza za pośrednictwem interfejsu API.
Hash transakcji przechodzi kilka weryfikacji przez serwer. Jeśli zostanie uznany za uzasadniony, osoba podpisująca podpisuje wiadomość i wysyła podpis z powrotem do interfejsu użytkownika za pośrednictwem interfejsu API.
Po otrzymaniu podpisu DApp weryfikuje go i upoważnia użytkownika do wycofania tokenów z łańcucha docelowego.
Serwer zaplecza musi upewnić się, że przetwarzana przez niego transakcja depozytowa rzeczywiście miała miejsce i nie jest fałszerstwem. Ten serwer zaplecza określa, czy użytkownik może wypłacić tokeny w łańcuchu docelowym, dlatego jest bardzo poszukiwanym celem ataku cyberprzestępców.
Serwer zaplecza musi sprawdzić strukturę wyemitowanego zdarzenia transakcji, a także adres kontraktu, który wyemitował zdarzenie. Jeśli to drugie zostanie zaniedbane, osoba atakująca może wdrożyć złośliwą umowę w celu sfałszowania zdarzenia wpłaty o tej samej strukturze, co prawidłowe zdarzenie wpłaty.
Jeśli serwer zaplecza nie sprawdzi, który adres wywołał zdarzenie, może uznać ją za prawidłową transakcję i podpisać wiadomość. Osoba atakująca może następnie wysłać skrót transakcji do backendu, omijając weryfikację i usuwając tokeny z łańcucha docelowego.
Niewłaściwa obsługa tokenów natywnych
Mosty stosują różne podejścia do obsługi tokenów natywnych i tokenów użytkowych. Na przykład w sieci Ethereum tokenem natywnym jest ETH, a większość tokenów użytkowych jest zgodna ze standardem ERC-20.
Jeśli użytkownik spróbuje przenieść swoje ETH do innej sieci, musi najpierw zdeponować je w umowie pomostowej. Aby to osiągnąć, użytkownik po prostu dołącza ETH do transakcji, a kwotę ETH można sprawdzić, czytając pole „msg.value” transakcji.
Wpłacanie tokenów ERC-20 bardzo różni się od deponowania ETH. Aby zdeponować token ERC-20, użytkownik musi najpierw pozwolić umowie pomostowej na wydanie swoich tokenów. Po zatwierdzeniu i zdeponowaniu tokenów w umowie pomostowej, umowa spali tokeny użytkownika za pomocą funkcji „burnFrom()” lub przekaże token użytkownika do umowy za pomocą funkcji „transferFrom()”.
Jednym ze sposobów rozróżnienia tego jest użycie instrukcji warunkowej w samej funkcji. Innym sposobem jest utworzenie dwóch oddzielnych funkcji do obsługi każdego scenariusza. Próba wpłaty ETH przy użyciu funkcji wpłaty dla ERC-20 może skutkować utratą środków.
Podczas obsługi wniosków o wpłatę ERC-20 użytkownicy zazwyczaj podają adres tokena jako dane wejściowe do funkcji wpłaty. Wiąże się to ze znacznym ryzykiem, gdyż w trakcie transakcji mogą wystąpić zawodne połączenia zewnętrzne. Wdrażanie białej listy zawierającej tylko tokeny obsługiwane przez most jest powszechną praktyką mającą na celu zminimalizowanie tego ryzyka. Jako argument można przekazywać wyłącznie adresy umieszczone na białej liście. Zapobiega to wywołaniom zewnętrznym, ponieważ zespół projektowy już ujawnił adres tokena.
Jednakże mogą pojawić się problemy, gdy mosty obsługują transfer tokenów natywnych w łańcuchu, ponieważ token natywny nie ma adresu. Adres zerowy (0x000...0) reprezentuje token natywny. Może to być problematyczne, ponieważ przekazanie adresu zerowego do funkcji może ominąć sprawdzanie białej listy, nawet jeśli jest poprawnie zaimplementowane.
Kiedy umowa pomostowa wywołuje „transferFrom”, aby przenieść zasoby użytkownika do kontraktu, zewnętrzne wywołanie adresu zerowego zwraca wartość false, ponieważ pod adresem zerowym nie ma zaimplementowanej funkcji „transferFrom”. Jednak transakcja może nadal nastąpić, jeśli kontrakt nie obsługuje prawidłowo zwracanej wartości. Stwarza to możliwość atakującym przeprowadzenia transakcji bez przekazywania jakichkolwiek tokenów do kontraktu.
Zła konfiguracja
W większości mostów blockchain osoba odpowiedzialna za umieszczanie na białej lub czarnej liście tokenów i adresów, przypisywanie lub zmianę sygnatariuszy oraz inne krytyczne konfiguracje pełni rolę uprzywilejowaną. Dokładność wszystkich ustawień ma kluczowe znaczenie, ponieważ nawet najbardziej pozornie błahe niedopatrzenia mogą prowadzić do znacznych strat.
W rzeczywistości miał miejsce incydent, w którym osoba atakująca pomyślnie ominęła weryfikację dziennika transferu z powodu błędnej konfiguracji. Zespół projektowy wdrożył aktualizację protokołu na kilka dni przed włamaniem, a aktualizacja ta obejmowała zmianę zmiennej. Zmienna została użyta do reprezentowania wartości domyślnej zaufanej wiadomości. Zmiana ta spowodowała, że wszystkie wiadomości były automatycznie klasyfikowane jako testowane, co umożliwiało atakującemu wysłanie dowolnej wiadomości i przejście procesu weryfikacji.
Jak poprawić bezpieczeństwo na mostach
Wyjaśnione do tej pory cztery najczęstsze luki w zabezpieczeniach mostów pokazują wyzwania związane z zapewnieniem bezpieczeństwa w połączonym ekosystemie blockchain. Należy wziąć pod uwagę istotne kwestie dotyczące obsługi każdej z tych luk i nie ma prostego rozwiązania, które sprawdziłoby się w przypadku każdej z nich.
Na przykład zapewnienie ogólnych wytycznych zapewniających bezbłędny proces weryfikacji jest trudne, ponieważ każdy most ma inne wymagania weryfikacyjne. Najbardziej skuteczną metodą zapobiegania obejściu weryfikacji jest dokładne przetestowanie mostu pod kątem potencjalnych wektorów ataku i upewnienie się, że logika weryfikacji jest solidna.
Krótko mówiąc, konieczne jest rygorystyczne testowanie potencjalnych ataków i zwracanie szczególnej uwagi na najczęstsze luki w zabezpieczeniach mostów.
Wnioski
Mosty krzyżowo-łańcuchowe ze względu na swoją dużą wartość od dawna są celem ataków. Deweloperzy mogą wzmocnić bezpieczeństwo swoich mostów, przeprowadzając szeroko zakrojone testy przed wdrożeniem i angażując się w audyty stron trzecich, zmniejszając ryzyko ponownego wystąpienia niszczycielskich włamań, które nękały mosty w ostatnich latach. Mosty mają kluczowe znaczenie w świecie wielołańcuchowym, ale bezpieczeństwo musi być priorytetem przy projektowaniu i budowaniu efektywnej infrastruktury Web3.
Dalsza lektura
Co to jest most blockchain?
Co to jest interoperacyjność między łańcuchami?
Trzy popularne mosty kryptograficzne i sposób ich działania
Czym są tokeny opakowane?
Nota prawna i ostrzeżenie o ryzyku: Niniejsza treść jest prezentowana w stanie „takim, jakim jest” wyłącznie w celach informacyjnych i edukacyjnych, bez jakichkolwiek oświadczeń ani gwarancji. Nie należy jej interpretować jako porady finansowej, prawnej lub innej profesjonalnej, ani też nie ma na celu rekomendowania zakupu jakiegokolwiek konkretnego produktu lub usługi. Powinieneś zasięgnąć indywidualnej porady u odpowiednich profesjonalnych doradców. Ponieważ ten artykuł został napisany przez stronę trzecią, należy pamiętać, że wyrażone opinie są opiniami strony trzeciej i niekoniecznie odzwierciedlają opinie Binance Academy. Aby uzyskać więcej informacji, przeczytaj naszą pełną informację prawną tutaj. Ceny aktywów cyfrowych mogą być zmienne. Wartość inwestycji może zarówno spaść, jak i wzrosnąć, a zainwestowana kwota może nie zostać zwrócona. Tylko Ty jesteś odpowiedzialny za swoje decyzje inwestycyjne. Binance Academy nie ponosi odpowiedzialności za jakiekolwiek straty, które możesz ponieść. Materiał ten nie powinien być interpretowany jako porada finansowa, prawna lub inna profesjonalna. Aby uzyskać więcej informacji, zapoznaj się z naszymi Warunkami użytkowania i Ostrzeżeniem o ryzyku.
