Napastnicy odpowiadają za 63% wczesnego wykorzystania nowej funkcji portfela inteligentnego Ethereum

Zachowanie skrótu portfela inteligentnego Ethereum pojawiło się z nowym problemem zaufania: portfel może uczynić zwykły adres programowalnym, nie przenosząc aktywów użytkownika, podczas gdy delegowany kod zyskuje moc działania z autorytetem tego konta.

Badanie recenzowane, opublikowane na konferencji USENIX Security '26, wykazało, że kontrakty powiązane z napastnikami były związane z 2 322 548 z 3 664 166 transakcji autoryzacyjnych EIP-7702, które zaobserwowano na siedmiu łańcuchach do 15 lipca 2025 roku. To 63% historycznej objętości transakcji w zbiorze danych badaczy.

Autorzy powiązali stosunkowo mały zestaw złośliwych kontraktów z powtarzającymi się autoryzacjami i opisali niektóre działania kontrolowane przez napastników jako prawdopodobnie praktykę lub testy dowodów koncepcji w wczesnej fazie eksploracyjnej.

Liczba ta mierzy transakcje, podczas gdy występowanie różnych portfeli oraz obecna stopa ataków w 2026 roku leżą poza zakresem badania.

Dlaczego napastnicy dominowali w wczesnym liczeniu autoryzacji

Ethereum aktywowało Pectra, w tym EIP-7702, 7 maja 2025 roku. Ostateczna specyfikacja wprowadziła transakcję typu 4, która pozwala zewnętrznie posiadanym kontom ustawić wskaźnik do wdrożonego kodu kontraktu.

Adres pozostaje ten sam, oryginalny klucz prywatny zachowuje kontrolę, a wywołania do konta mogą wykonywać delegowany kod w kontekście konta.

Ten projekt może nadać konwencjonalnemu portfelowi cechy związane z inteligentnymi kontami, w tym zgrupowane wywołania i sponsorowane transakcje, bez zmuszania użytkownika do migracji do nowego adresu. Przekształca również cel delegacji w infrastrukturę portfela.

Błędny lub wrogi kod może być w stanie dokonywać zatwierdzeń, transferów i wywołań aplikacji jako konto.

Mówi, że aplikacje nie powinny oczekiwać, że poproszą użytkowników o dowolne podpisy autoryzacyjne, ponieważ nie ma bezpiecznego ogólnego interfejsu, aby użytkownicy mogli ocenić kod z nieograniczonym dostępem do konta. Oczekuje się, że portfele będą weryfikować wdrożenie.

Napastnicy mogą przygotować pola autoryzacji poza łańcuchem i poprosić ofiarę o podpisanie, a portfel może zredukować decyzję do ogólnego komunikatu o aktualizacji konta, jednocześnie ukrywając adres kontraktu lub kod otrzymujący autorytet.

Protokół weryfikuje podpis właściciela konta, podczas gdy portfel nadal musi ustalić, czy wybrany kod zasługuje na kontrolę.

Badacze przeanalizowali ponad 22,8 miliarda historycznych transakcji na Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base i Gnosis.

W ramach tych danych zbadali 3 664 166 autoryzacji EIP-7702 do momentu odcięcia i użyli filtrów transakcji, analizy kodu bajtowego oraz przeglądu ręcznego, aby zidentyfikować 924 złośliwe kontrakty. Klasyfikowali 793 jako ukierunkowane na EOA, 124 jako ukierunkowane na konta kontraktowe i siedem jako ataki złożone.

Mapa ryzyka EIP-7702 pokazuje, że 63% autoryzacji, 2,36 miliona dolarów wykrytych strat oraz 10,14 miliona dolarów potencjalnej ekspozycji.

Dokument wskazuje, że złośliwe kontrakty były wykorzystywane w sposób nieproporcjonalny, co sprawia, że liczba transakcji może rosnąć znacznie szybciej niż liczba odrębnych kontraktów czy dotkniętych użytkowników. W młodym rynku autoryzacji, powtarzająca się aktywność napastników miała ogromny wpływ na mianownik.

Napastnicy znaleźli powtarzalną drogę do autoryzacji na poziomie konta, zanim portfele podjęły decyzję o zaufaniu, która była tak czytelna i ograniczona jak moc, którą przekazywała.

Ryzyko wykracza poza przejęte portfele

Badanie zmierzyło 2 362 848,76 dolarów wykrytych strat w trzech kategoriach ataków. Oddzielna ocena obejmowała starsze kontrakty, których zabezpieczenia zakładały, że programowalne EOA nie mogą istnieć.

EIP-7702 łamie starą zasadę, że msg.sender == tx.origin niezawodnie identyfikuje zwykłe EOA lub blokuje zachowanie pośredniczone przez kontrakt.

Badacze zidentyfikowali 967 aktywnych kontraktów Ethereum w podzbiorze, które używały tego sprawdzenia jako obrony przed pożyczkami błyskawicznymi i oszacowali, że około 10,1 miliona dolarów w aktywach było narażonych na wysokie ryzyko.

Wykryta kradzież wyniosła około 2,36 miliona dolarów, więc 10,14 miliona dolarów reprezentuje aktywa narażone przez obronną zasadę, która już nie obowiązywała.

Badacze zaobserwowali, że napastnicy ponownie przypisywali konta do nieszkodliwego kodu po ataku, co czyni monitoring oparty na aktualnym stanie niewiarygodnym. Odkryli również 500 specjalnych celów delegacji z nieprzydzielonym kodem.

Wstępnie obliczony adres CREATE2 mógłby otrzymać kod później, zmieniając to, co konto wykonuje, podczas gdy zarejestrowany cel pozostaje ten sam.

Te wzorce sprawiają, że historia autoryzacji staje się częścią granicy bezpieczeństwa. Portfele i narzędzia monitorujące muszą pamiętać, gdzie konto wcześniej wskazywało, oceniać zmiany w delegowanym kodzie i traktować nieprzydzielony cel jako nierozwiązany, a nie nieszkodliwy.

Zasady autorów mogą przeoczyć złośliwe kontrakty, zanim transakcje przygotowawcze staną się widoczne lub ataki wykorzystujące nowe interfejsy poza zakresem metody. 924 kontrakty to wykryty i ręcznie zweryfikowany zestaw, podczas gdy całkowity wszechświat nadużyć pozostaje nieznany.

Bezpieczne domyślne zachowanie zaczyna się od uczynienia delegacji decyzją instalacyjną kontrolowaną przez portfel. Wytyczne ethereum.org po badaniach wzywają do białej listy kontraktów delegacyjnych, wyraźnego wyświetlania celu, unikania dowolnej delegacji na portfelach sprzętowych oraz polegania na audytowanych implementacjach.

Propozycja możliwości portfela abstrakcji konta podąża w tym samym kierunku, wzywając do ścisłej listy znanych, publicznie audytowanych implementacji inteligentnych kont. Te dokumenty nie mierzą, jak konsekwentnie produkcyjne portfele je przyjęły.

Aplikacje powinny żądać funkcji, których potrzebują, i pozostawić implementację konta portfelowi. Dla zatwierdzenia i wymiany w jednym przepływie, obecne wytyczne Fundacji Ethereum wskazują deweloperów na interfejs portfela, taki jak ERC-5792.

Portfel może następnie wybrać EIP-7702, ERC-4337 lub inny system konta bez pytania użytkownika o zatwierdzenie kodu delegacji na niskim poziomie wybranego przez aplikację.

Aktualne wytyczne zalecają podpisywanie parametrów inicjalizacji lub ograniczenie konfiguracji do EntryPoint ERC-4337, co zamyka ścieżkę front-running, w której atakujący może zastąpić własne wartości.

Badanie zidentyfikowało powiązany tryb awarii w kodzie starych portfeli: konstruktory nie uruchamiają się ponownie, gdy konto deleguje do istniejącego kontraktu, co może pozostawić nieustaloną własność, którą można rościć z zewnątrz.

Nieszkodliwy wskaźnik bieżący nie może wymazać złośliwej historii, a cel bez kodu może nabyć zachowanie później. Portfele potrzebują trwałych zapisów autoryzacji, jasnych powiadomień, gdy delegacja się zmienia, oraz ścieżki usunięcia, którą użytkownicy mogą zrozumieć.

Aby domyślnie uczynić programowalność portfela EIP-7702 bezpieczną, portfele muszą traktować delegację jako instalację płaszczyzny kontrolnej konta: ograniczyć, kto może o nią prosić, ujawniać dokładnie, co będzie kontrolować konto, weryfikować, jak się inicjalizuje, i nadal obserwować po zmianie wskaźnika.

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.