Быстрый путь Ethereum к поведению смарт-кошельков столкнулся с новой проблемой доверия: кошелек может сделать обычный адрес программируемым, не перемещая активы пользователя, при этом делегированный код получает возможность действовать с полномочиями этого аккаунта.
Рецензируемое исследование, представленное на USENIX Security ’26, показало, что связанные с атакующими контракты были связаны с 2 322 548 из 3 664 166 транзакций авторизации EIP-7702, которые наблюдались на семи цепочках по состоянию на 15 июля 2025 года. Это составляет 63% от общего объема исторических транзакций в наборе данных исследователей.
Авторы связали относительно небольшой набор вредоносных контрактов с повторными авторизациями и описали некоторую активность под контролем атакующих как вероятное тестирование или проверку концепции на раннем, исследовательском этапе.
Показатель измеряет транзакции, при этом распространенность среди отдельных кошельков и текущий уровень атак в 2026 году выходят за рамки исследования.
Почему атакующие доминировали на раннем этапе подсчета авторизаций
Ethereum активировал обновление Pectra, включающее EIP-7702, 7 мая 2025 года. Финальная спецификация ввела транзакцию типа 4, которая позволяет внешне управляемому аккаунту (EOA) установить указатель на код развернутого контракта.
Адрес остается прежним, исходный закрытый ключ сохраняет контроль, а вызовы к аккаунту могут выполнять делегированный код в контексте этого аккаунта.
Такая конструкция может дать обычному кошельку функции, присущие смарт-аккаунтам, включая пакетные вызовы и спонсируемые транзакции, без необходимости миграции пользователя на новый адрес. Она также превращает цель делегирования в инфраструктуру кошелька.
Ошибочный или вредоносный код может совершать одобрения, переводы и вызовы приложений от имени аккаунта.
В документе говорится, что приложения не должны ожидать запроса от пользователей произвольных подписей авторизации, поскольку не существует безопасного универсального интерфейса для оценки пользователями кода с неограниченным доступом к аккаунту. Предполагается, что кошельки будут проверять реализацию.
Атакующие могут подготовить поля авторизации вне сети и попросить жертву подписать их, а кошелек может свести решение к подсказке о высокоуровневом обновлении аккаунта, скрывая при этом адрес контракта или код, получающий полномочия.
Протокол проверяет подпись владельца аккаунта, в то время как кошелек все еще должен установить, заслуживает ли выбранный код контроля.
Исследователи проанализировали более 22,8 миллиарда исторических транзакций на Ethereum, Binance Smart Chain, Polygon, Optimism, Arbitrum, Base и Gnosis.
В этих данных они изучили 3 664 166 авторизаций EIP-7702 до контрольной даты и с помощью фильтров транзакций, анализа байт-кода и ручной проверки выявили 924 вредоносных контракта. Они классифицировали 793 как нацеленные на EOA, 124 — на контрактные аккаунты и семь — как комбинированные атаки.
| Параметр исследования | Что он показывает |
|---|---|
| 3 664 166 авторизаций | Исторические транзакции EIP-7702 по семи цепочкам по состоянию на 15 июля 2025 года |
| 2 322 548 авторизаций, или 63% | Исторические транзакции, связанные с вредоносными контрактами, нацеленными на EOA |
| 924 вредоносных контракта | Обнаруженный и проверенный вручную набор в рамках метода исследователей |
| $2,36 млн | Обнаруженный реализованный убыток по трем категориям атак |
| Около $10,14 млн | Потенциальная подверженность риску в отдельном подмножестве устаревших контрактов |
В статье говорится, что вредоносные контракты использовались непропорционально часто, поэтому количество транзакций может расти гораздо быстрее, чем количество отдельных контрактов или затронутых пользователей. На молодом рынке авторизаций такая повторная активность атакующих оказала непропорционально большое влияние на знаменатель.
Атакующие нашли повторяемый путь к получению полномочий на уровне аккаунта до того, как кошельки сделали решение о доверии столь же понятным и ограниченным, как и предоставляемые им полномочия.
Риск выходит за рамки взломанных кошельков
Исследование оценило реализованные убытки в $2 362 848,76 по трем категориям атак. Отдельная оценка касалась более старых контрактов, защита которых предполагала, что программируемые EOA не могут существовать.
EIP-7702 нарушает старое предположение, что msg.sender == tx.origin надежно идентифицирует обычный EOA или блокирует поведение, опосредованное контрактом.
Исследователи выявили 967 активных контрактов Ethereum в подмножестве, использующих эту проверку в качестве защиты от флеш-кредитов, и оценили, что активы на сумму около $10,1 млн находились в потенциальной зоне высокого риска.
Обнаруженные кражи составили около $2,36 млн, поэтому $10,14 млн представляют собой активы, подвергшиеся риску из-за защитного предположения, которое больше не действует.
Исследователи наблюдали, как атакующие после атаки перепривязывали аккаунты к безвредному коду, что делало мониторинг только текущего состояния ненадежным. Они также обнаружили 500 специальных целей делегирования с ненулевым значением, у которых не было развернутого кода.
Предварительно вычисленный адрес CREATE2 может получить код позже, изменяя то, что выполняет аккаунт, в то время как записанная цель остается прежней.
Эти шаблоны делают историю авторизаций частью границы безопасности. Кошелькам и инструментам мониторинга необходимо помнить, куда ранее указывал аккаунт, оценивать изменения в делегированном коде и рассматривать неразвернутую цель как нерешенную, а не безвредную.
Правила авторов могут не учитывать вредоносные контракты до того, как подготовительные транзакции станут видимыми, или атаки с использованием новых интерфейсов, выходящих за рамки охвата метода. 924 контракта — это обнаруженный и проверенный вручную набор, в то время как общий масштаб злоупотреблений остается неизвестным.
Безопасное поведение по умолчанию начинается с того, что делегирование становится решением об установке, контролируемым кошельком. Опубликованные после исследования рекомендации ethereum.org призывают к использованию белого списка контрактов делегирования, четкому отображению цели, отказу от произвольного делегирования на аппаратных кошельках и опоре на аудированные реализации.
Предложение по возможностям кошелька для абстракции аккаунта идет в том же направлении, призывая к строгому короткому списку хорошо известных, публично аудированных реализаций смарт-аккаунтов. Эти документы не измеряют, насколько последовательно производственные кошельки их приняли.
Приложения должны запрашивать необходимую им функцию и оставлять реализацию аккаунта на усмотрение кошелька. Для одобрения и обмена в одном потоке текущие рекомендации Ethereum Foundation указывают разработчикам на интерфейс кошелька, такой как ERC-5792.
Затем кошелек может выбрать EIP-7702, ERC-4337 или другую систему аккаунтов, не прося пользователя одобрять низкоуровневый код делегирования, выбранный приложением.
Текущие рекомендации предлагают подписывать параметры инициализации или ограничивать настройку EntryPoint ERC-4337, закрывая путь фронтраннинга, при котором атакующий подставляет свои собственные значения.
Исследование выявило связанный режим отказа в устаревшем коде кошельков: конструкторы не запускаются повторно, когда аккаунт делегирует существующему контракту, что может оставить владение неустановленным и доступным для внешнего захвата.
Безвредный текущий указатель не может стереть вредоносную историю, а цель без кода может приобрести поведение позже. Кошелькам нужны долговечные записи авторизаций, четкие предупреждения при изменении делегирования и путь удаления, понятный пользователям.
Чтобы сделать программируемость кошелька EIP-7702 безопасной по умолчанию, кошельки должны рассматривать делегирование как установку плоскости управления аккаунтом: ограничивать, кто может его запрашивать, точно раскрывать, что будет управлять аккаунтом, проверять, как оно инициализируется, и продолжать наблюдение после изменения указателя.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
