Użytkownik Ethereum stracił około 7,73 mln USD w rsETH po tym, jak napastnik wykorzystał ścieżkę wykonywania modułu Safe do przekierowania aktywów przez kontrolowaną przez siebie pulę płynności Uniswap v4.

Zaadresowany portfel Safe (0x40e93a52f6af9fcd3b476aedadd7feabd9f7aba8) został zaatakowany we wczesnych godzinach 15 września. Monitoring bezpieczeństwa zidentyfikował dwie transakcje odpowiedzialne za stratę. Dostępne dowody wskazują na niestandardowy moduł portfela i jego interakcję ze złośliwym hookiem, a nie na lukę w podstawowych kontraktach smart accountów Safe.

Niestandardowy moduł skierował aktywa do złośliwej puli

Atak wykorzystał publiczny multicall keepera do wywołania niestandardowego modułu Uni V4 LP Safe podłączonego do konta. Wykonanie transakcji skierowało płynność do puli Uniswap v4 utworzonej z hookiem kontrolowanym przez napastnika, umożliwiając złośliwej logice routingu dostęp do aktywów związanych z pozycją.

Następnie hook zamienił pozycję ofiary w aEthrsETH na transferowalne rsETH. aEthrsETH reprezentuje rsETH dostarczone do Aave, dlatego napastnik musiał najpierw wyprowadzić pozycję z formy tokena-kwitu Aave, zanim mógł wydobyć bazowe rsETH.

Architektura modułów Safe pozwala autoryzowanym rozszerzeniom wykonywać transakcje niezależnie od standardowego procesu wielopodpisowego. Moduły mogą automatyzować złożone operacje DeFi, ale Safe ostrzega, że mają one kluczowe znaczenie dla bezpieczeństwa, ponieważ aktywowany złośliwy lub podatny moduł może wykonywać dowolne transakcje z konta. Dokumentacja Safe dotycząca modułów jest dostępna tutaj.

Ponieważ publiczny multicall keepera mógł wywołać niestandardowy moduł konta, istotna granica bezpieczeństwa wykraczała poza przepływ podpisów Safe i obejmowała autoryzację modułu oraz logikę transakcji. W przypadku podobnych kont obsługujących DeFi sama analiza kontraktu Safe nie opisywałaby w pełni aktywnej powierzchni wykonywania konta.

Atak nie doprowadził do przejęcia podstawowych kontraktów multisig Safe, kluczy podpisujących ani samego Ethereum. Zidentyfikowana ścieżka awarii obejmowała niestandardowy moduł konta i hook Uniswap v4 kontrolowany przez napastnika. Podobne rozdzielenie ujawniło się w maju, gdy exploit SquidRouterModule opróżnił 86 kont Safe w sieciach Ethereum i Base, pozostawiając bazowe kontrakty Safe poza zidentyfikowaną ścieżką awarii.

Bot MEV przejął ekstrakcję

Transakcja ataku została przechwycona w obrębie bloku przez operację MEV powiązaną z adresem, który Etherscan oznacza jako MEV Frontrunner Yoink.

Bot wyprzedził pierwotną ekstrakcję i przejął dochodową ścieżkę transakcji, zanim napastnik zdołał ją zrealizować w przesłanej formie. Ofiara nadal straciła rsETH, ponieważ bazowe złośliwe wykonanie zakończyło się powodzeniem, natomiast kolejność transakcji zmieniła adres zewnętrzny, który ostatecznie przejął znaczną część wyekstrahowanej wartości.

Portfel Safe pozostał wyłącznie z NFT reprezentującym pozycję płynności w złośliwej puli, zamiast zabezpieczonej rsETH pozycji, którą posiadał przed tymi transakcjami.

rsETH ponownie skupia uwagę w obszarze bezpieczeństwa

rsETH to token płynnego restakingu Kelp DAO, który pozostaje zintegrowany z rynkami pożyczek i płynności w sieci Ethereum. Jego wykorzystanie w Aave utworzyło zabezpieczenie aEthrsETH związane z opróżnieniem portfela.

Token Kelp doświadczył również poważnego incydentu bezpieczeństwa na początku tego roku. W wyniku kwietniowego exploitu Kelp DAO z infrastruktury międzyłańcuchowej uwolniono około 292 mln USD w rsETH, co stworzyło znaczną ekspozycję wtórną na rynkach pożyczek DeFi.

Strata z 15 września jest odrębnym zdarzeniem. Obecne dowody koncentrują się na wykonaniu modułu pojedynczego portfela Safe, hooku Uniswap v4 kontrolowanym przez napastnika oraz wynikającej z tego konwersji zabezpieczonej w Aave pozycji rsETH portfela. Nie ustalono szerszego przejęcia Safe, Aave, Kelp DAO ani kontraktu tokena rsETH.

Źródło: Crypto Adventure.