To jest rodzaj błędu, który nie pozwala zespołom protokołów spać w nocy. Eksploatacja na kwotę 5 milionów dolarów w ZKSwap, spowodowana przez jedno zdanie pozostawione w złym miejscu. Oto szczegółowe omówienie, jak to się stało i jak monitorowanie on-chain mogłoby temu zapobiec. 🧵

1/ 9 lipca GMX został zhakowany na kwotę 42 milionów dolarów. Ale tego dnia wydarzyło się coś jeszcze, co ledwie ktoś zauważył: most ZKSwap został cicho opróżniony na kwotę 5 milionów dolarów. Ciekawa część? Nie było żadnego wymyślnego exploit'u. Po prostu krytyczna funkcja, która… nic nie robiła.

2/ ZKSwap to zk-rollup zbudowany na Ethereum. Jak wiele rollupów, używa mostu do przenoszenia aktywów między L1 a L2. Jako zabezpieczenie, most zawiera „Tryb Exodus”, sposób dla użytkowników na odzyskanie funduszy bez potrzeby angażowania operatora. Teoretycznie to świetny pomysł. W praktyce…

3/ Tryb Exodus pozwala użytkownikom ręcznie udowodnić, że posiadali tokeny w ostatnim zweryfikowanym stanie L2. To mechanizm awaryjny: bez zaufania, samodzielne przechowywanie, nieinteraktywne. Jednak implementacja ZKSwap miała jeden fatalny błąd: Funkcja odpowiedzialna za weryfikację dowodów nie weryfikowała niczego. Dosłownie.

4/ Oto kod, który powinien był zatrzymać atak 👇 Na pierwszy rzut oka wygląda jak prawdziwy weryfikator zk-proof. Ale przyjrzyj się uważnie pierwszej linii: return true; To wszystko. Nic więcej się nie wykonuje.

5/ Jaki jest wynik? Każdy „dowód” wypłaty (bez względu na to, jak fałszywy) przeszedł walidację. Kontrakt akceptował dowolne roszczenia dotyczące sald tokenów... i przypisywał je, jakby były prawdziwe. Przekształcił bezpieczny mechanizm awaryjny w niechroniony kran.

6/ Napastnik nie potrzebował wyszukanych exploitów - wystarczyły powtarzające się wywołania exit() z wymyślonymi danymi. Ominięto kontrole salda, wypłacono przez wiele tokenów i wykorzystano słabą logikę nullifiera, aby uniknąć wykrycia. Wszystko to podczas gdy kontrakt mówił: ✅

7/ To nie był jakiś niejasny przypadek brzegowy. To była podstawowa logika odzyskiwania aktywów, pozostawiona całkowicie otwarta. A ponieważ tryb Exodus rzadko jest uruchamiany, uszkodzona ścieżka pozostała niezauważona... przez miesiące.

8/ Oto co powinno było wywołać alarmy: • Aktywacja trybu Exodus po długim okresie bezczynności • Dziesiątki jednoczesnych wezwań do wypłaty • Nagły wzrost zmian w saldach do wypłaty Wszystko to było widoczne i mogło zostać zatrzymane dzięki monitorowaniu on-chain w czasie rzeczywistym.

9/ Jaka jest lekcja? • Kod awaryjny to wciąż kod produkcyjny • Ścieżki zapasowe nie pomagają, jeśli nie działają • Monitorowanie w czasie rzeczywistym nie jest opcjonalne, to kwestia przetrwania