Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent związany z botem MEV JaredFromSubway pokazuje, że automatyzacja w środowisku DeFi może tworzyć nowe, bardzo kosztowne powierzchnie ataku. W tym przypadku napastnik nie przełamał klasycznych mechanizmów kryptograficznych blockchaina, lecz wykorzystał logikę biznesową i sposób, w jaki bot automatycznie oceniał okazje transakcyjne oraz nadawał uprawnienia kontraktom pomocniczym. To przykład ataku na warstwę aplikacyjną i decyzyjną systemu on-chain.
W skrócie
Bot Ethereum należący do operacji JaredFromSubway stracił około 15 mln dolarów w wyniku manipulacji fałszywymi okazjami MEV. Napastnik przygotował kontrakty i pule wyglądające na rentowne, skłaniając automat do zatwierdzania uprawnień ERC-20 dla kontrolowanych przez siebie kontraktów. Uprawnienia te nie zostały następnie skonsumowane ani cofnięte, co pozwoliło później wyprowadzić środki za pomocą funkcji transferFrom. Według opisu incydentu skradzione zostały m.in. aktywa WETH, USDC i USDT. Po ataku operator próbował odzyskać środki, oferując nagrodę finansową za ich zwrot.
Kontekst / historia
JaredFromSubway jest rozpoznawalną, prywatną operacją MEV na Ethereum, kojarzoną szczególnie z agresywnymi strategiami typu sandwich. Tego rodzaju boty monitorują mempool i próbują zarabiać na kolejności oraz czasie realizacji transakcji, często wstawiając własne zlecenia przed i po transakcji ofiary. Chociaż mechanizmy MEV są technicznie zgodne z działaniem sieci, budzą kontrowersje, ponieważ zwykle pogarszają warunki realizacji transakcji dla zwykłych użytkowników i przenoszą wartość do operatorów zaawansowanej infrastruktury automatycznego handlu.
W analizowanym przypadku problem nie dotyczył samej koncepcji MEV, lecz zaufania, jakie system wykonawczy bota przyznawał wykrywanym okazjom. Jeżeli silnik automatycznie tworzący ścieżki transakcji i wywołania kontraktów nie ma wystarczających zabezpieczeń semantycznych, napastnik może spreparować scenariusz, który wygląda na zyskowny, ale w rzeczywistości prowadzi do nadania nadmiernych uprawnień i utraty środków.
Analiza techniczna
Z dostępnych informacji wynika, że napastnik przygotował złośliwe kontrakty zaprojektowane tak, aby wyglądały jak opłacalne okazje arbitrażowe lub inne szanse MEV. Bot automatycznie analizował trasy i potencjalne zyski, po czym generował transakcje niezbędne do wykonania strategii. Kluczowym elementem było udzielanie zatwierdzeń ERC-20, czyli approvals, kontraktom pomocniczym wskazanym w przygotowanej przez napastnika ścieżce wykonania.
Mechanizm approval w standardzie ERC-20 pozwala właścicielowi tokenów upoważnić inny adres do wydawania środków do określonego limitu. Samo nadanie uprawnienia nie oznacza jeszcze kradzieży, ale tworzy warunek wstępny do późniejszego pobrania aktywów. W tym incydencie pierwsze transakcje miały charakter testowy i prawdopodobnie służyły do potwierdzenia wzorców działania automatu. Następnie napastnik zmodyfikował trasę wykonania w taki sposób, aby przyznane uprawnienia nie zostały zużyte ani unieważnione po zakończeniu operacji.
W efekcie złośliwy kontrakt zachował ważne uprawnienia do dysponowania aktywami bota. Według relacji limit zatwierdzenia sięgał co najmniej 92,1614 WETH dla jednego z kontraktów pomocniczych kontrolowanych przez napastnika. Po zgromadzeniu wystarczających approvals atakujący wykonał właściwy etap eksfiltracji, używając funkcji transferFrom do pobrania tokenów z kontraktu bota. Ten wzorzec ataku jest szczególnie istotny z perspektywy bezpieczeństwa smart kontraktów, ponieważ nie wymaga kompromitacji klucza prywatnego ofiary. Wystarczy wymusić poprawne z perspektywy EVM, ale niebezpieczne logicznie autoryzacje.
Technicznie rzecz ujmując, incydent można opisać jako kombinację:
- manipulacji logiką wykrywania okazji,
- nadużycia modelu autoryzacji ERC-20,
- braku skutecznych ograniczeń dla kontraktów docelowych,
- niewystarczającej walidacji ścieżki wykonania przed nadaniem approval,
- braku mechanizmu natychmiastowego cofania lub ograniczania uprawnień po użyciu.
Konsekwencje / ryzyko
Najbardziej bezpośrednią konsekwencją była utrata około 15 mln dolarów w aktywach cyfrowych. Z punktu widzenia bezpieczeństwa ważniejsze są jednak szersze implikacje dla ekosystemu DeFi i operatorów automatycznych strategii handlowych.
Po pierwsze, incydent pokazuje, że systemy MEV są narażone nie tylko na konkurencję rynkową, ale również na celowe pułapki logiczne tworzone przez przeciwników. Po drugie, każda architektura oparta na szerokich approvals stanowi atrakcyjny cel, szczególnie gdy decyzje o nadaniu uprawnień są podejmowane autonomicznie i przy dużej częstotliwości. Po trzecie, w środowiskach o wysokiej zmienności i bardzo krótkim czasie reakcji tradycyjne praktyki review i manualnego zatwierdzania są często pomijane, co zwiększa ryzyko błędów projektowych.
Dla organizacji budujących boty handlowe, silniki routingu lub automaty arbitrażowe oznacza to konieczność traktowania logiki transakcyjnej jak krytycznego komponentu bezpieczeństwa. Nawet jeśli sam smart kontrakt jest formalnie poprawny, podatność może istnieć w algorytmie wyboru kontrahenta, modelu zaufania do puli płynności albo sekwencji approvals i wywołań.
Rekomendacje
Operatorzy botów MEV, platform DeFi i systemów automatycznego handlu powinni wdrożyć kilka warstw kontroli ograniczających podobne scenariusze:
- Minimalizacja approvals — zamiast szerokich i długotrwałych autoryzacji należy stosować możliwie najmniejsze limity, najlepiej jednorazowe lub ściśle powiązane z konkretną operacją.
- Allowlisty kontraktów i pul — bot nie powinien nadawać uprawnień dowolnym adresom wykrytym przez silnik okazji. W praktyce potrzebna jest lista zaufanych kontraktów, routerów, vaultów i adapterów.
- Walidacja semantyczna ścieżki wykonania — sama prognoza zysku nie może być jedynym kryterium akceptacji transakcji. Należy sprawdzać m.in. pochodzenie tokena, historię kontraktu, zgodność interfejsów, nieoczekiwane skutki uboczne i finalny stan approvals po zakończeniu operacji.
- Automatyczne cofanie uprawnień — po wykonaniu transakcji system powinien aktywnie zerować allowance, jeśli nie jest ono już potrzebne. Dodatkowo warto wdrożyć watchdog monitorujący otwarte approvals w czasie rzeczywistym.
- Symulacje i sandboxing — każda nietypowa ścieżka powinna być uruchamiana najpierw w środowisku symulacyjnym z analizą skutków ubocznych. Dotyczy to szczególnie tras obejmujących nowe pule, nowe tokeny i nieznane kontrakty pomocnicze.
- Limity ryzyka na poziomie silnika strategii — system powinien posiadać maksymalne progi ekspozycji na pojedynczy kontrakt, token, trasę i klasę strategii. Przekroczenie limitu powinno wstrzymywać wykonanie.
- Monitoring on-chain i alerting — potrzebne są reguły wykrywające nietypowe approvals, nagły wzrost allowance, wielokrotne testowe wywołania oraz transferFrom wykonywane przez rzadko używane adresy.
- Audyty logiki off-chain — w praktyce wiele krytycznych błędów nie leży w samym kodzie smart kontraktu, lecz w silniku decyzyjnym off-chain. Audyt bezpieczeństwa musi obejmować parser okazji, router transakcyjny, polityki approvals i mechanizmy awaryjnego zatrzymania.
Podsumowanie
Atak na bota JaredFromSubway jest ważnym studium przypadku dla bezpieczeństwa DeFi. Pokazuje, że najbardziej kosztowne incydenty nie zawsze wynikają z błędu kryptograficznego czy klasycznej podatności EVM. Wystarczy przekonać zautomatyzowany system do wykonania logicznie niebezpiecznej, lecz technicznie poprawnej sekwencji działań. Dla operatorów infrastruktury on-chain kluczowe staje się dziś nie tylko szybkie wykrywanie okazji rynkowych, ale przede wszystkim kontrola zaufania, uprawnień i kontekstu wykonania każdej transakcji.
Źródła
- BleepingComputer — JaredFromSubway MEV bot hacked in $15 million crypto theft — https://www.bleepingcomputer.com/news/security/jaredfromsubway-mev-bot-hacked-in-15-million-crypto-theft/