Детальный разбор механизма фишинговой атаки 7702: как защититься кошелькам и пользователям?

EIP-7702 предоставляет адресам возможности и гибкость, аналогичные смарт-контрактам. Создается все больше приложений на базе 7702, что имеет критическое значение для привлечения большего числа пользователей в Web3 и улучшения пользовательского опыта.

Однако мошеннические группы эксплуатируют гибкость протокола 7702 и тот факт, что большинство пользователей еще не знакомы с ним. Недавно мы зафиксировали случай, когда пользователи MetaMask подверглись краже средств из-за возможности пакетного выполнения через 7702: злоумышленники из группы #InfernoDrainer объединили множество отдельных действий, требующих десятка подтверждений, в одну транзакцию, что привело к потере активов.

Примечание: В самой MetaMask нет проблем с безопасностью. При предоставлении пользователям возможностей, связанных с 7702, приоритетом безопасности является защита пользователей, и реализовано множество мер предосторожности. Пользователям необходимо лучше понимать функциональность 7702 и связанные с ней риски, чтобы предотвратить повторение подобных инцидентов.

1. Принцип и механизм безопасной конструкции подписания авторизации 7702 Delagator в MetaMask

1. Технический анализ

• Пользователь авторизует уже развернутый контракт делегата (Delagator Contract), направляя поле code своего счета на этот контракт. Текущий официальный адрес контракта делегата MetaMask: 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B

• Структура авторизации: (chainId, delegatorAddress, nonce, signature) записывается в authorization_list

• Метод подписания: MetaMask использует унифицированную логику подписания для транзакций авторизации EIP-7702 на нижнем уровне — метод signEIP7702Authorization. Он выполняет ECDSA-подписание данных авторизации digest7702 = keccak256(0x05 ‖ RLP(chainId, delegator, nonce)), формирует структуру подписи (v, r, s) и прикрепляет её к последующей транзакции типа 4 для реализации авторизации и обновления учетной записи. Подробная реализация доступна по ссылке: https://github.com/MetaMask/eth-sig-util/blob/main/src/sign-eip7702-authorization.ts

• Метод проверки: уровень консенсуса завершает проверку с помощью функции ecrecover(digest7702, sig) == tx.from.

• Дизайн безопасности: веб-сайты не могут заманить пользователя на подпись авторизации для произвольного делегата, поскольку метод signEIP7702Authorization реализован исключительно внутри кошелька MetaMask и не доступен для вызова через window.ethereum**。** Доступные веб-страницам методы подписания, такие как eth_signTypedData_v4, не подходят для создания подписей EIP-7702; формат дайджеста подписи выглядит следующим образом:

Требования стандарта EIP-7702 предъявляют к формату подписи следующее:

Поскольку eth_signTypedData_v4 всегда содержит префикс 0x1901, а процесс вычисления дайджеста кардинально отличается от алгоритма 7702, то даже при тщательно подобранном domainSeparator, primaryType и message практически невозможно добиться равенства digest712 == digest7702.

Таким образом, веб-страницы не могут с помощью данного метода подделать легитимную подпись авторизации 7702. Кроме того, MetaMask применяет механизм белого списка для адресов делегатов, по умолчанию разрешая авторизацию только официального делегата (0x63c0...32B) и запрещая DApps самостоятельно внедрять адреса, что дополнительно предотвращает заманивание пользователей на подпись вредоносных данных авторизации делегата.

2. Способы использования

В настоящее время в MetaMask существуют два основных способа перевода действующего EOA в смарт-аккаунт (Smart Account) на базе 7702: проактивное обновление и реактивное обновление.

Проактивное обновление означает, что пользователь вручную нажимает кнопку «Переключить» в интерфейсе кошелька для авторизации конкретного контракта делегата.

Реактивное обновление происходит, когда пользователь взаимодействует с определенными DApps, поддерживающими 7702. После обнаружения соответствующих операций MetaMask автоматически выдает уведомление с предложением завершить обновление.

2.1 Проактивное обновление:

• Содержимое транзакции: включает только действие по обновлению этого аккаунта, то есть авторизацию конкретного контракта делегата.

• Процесс обновления: перейдите в интерфейс деталей учетной записи кошелька и нажмите кнопку «Переключить», указанную на изображении ниже, чтобы перевести аккаунт пользователя в статус смарт-аккаунта в сети Ethereum Mainnet. После нажатия кнопки появляется окно для подписания пользователем текущей транзакции обновления:

• Запись авторизации: после подтверждения дождитесь включения транзакции в блок. Успешное включение означает успешное обновление аккаунта до смарт-аккаунта. Детальную информацию о транзакциях авторизации можно просмотреть на странице текущего адреса кошелька в etherscan в разделе **Authorizations (EIP-7702)**.

2.2 Реактивное обновление

• Содержимое транзакции: включает действие по обновлению аккаунта, а также пакетные действия взаимодействия с контрактами в сети.

• Процесс обновления: при взаимодействии пользователя с некоторыми DApps в сети MetaMask самостоятельно предупреждает пользователя, что текущую транзакцию можно выполнить путем обновления до смарт-аккаунта и пакетной отправки. Например, при выполнении свопа некоторых токенов в Uniswap необходимо нажать кнопку Use smart account, обновиться до смарт-аккаунта, после чего авторизация токена и сам своп будут выполнены пакетно в одной транзакции.

2.3 Возврат к обычному EOA

Независимо от того, используется ли проактивное или реактивное обновление для перевода текущего аккаунта в смарт-аккаунт, адрес связанного контракта делегата будет постоянно храниться в сети и служить текущей логикой выполнения аккаунта.

Если пользователь хочет вернуть аккаунт в обычный статус EOA, ему необходимо вручную инициировать операцию «Переключить обратно в EOA». По своей сути эта операция представляет собой предоставление авторизации EIP-7702, где адрес address(0) указывается в качестве адреса нового контракта делегата. После успешного включения этой транзакции в блок поле code аккаунта будет очищено, логика выполнения вернется к значению по умолчанию (пустой код), и аккаунт снова перейдет в состояние обычного EOA.

Перейдите в интерфейс деталей учетной записи кошелька и нажмите кнопку переключения, чтобы перевести пользователя в сеть Ethereum Mainnet обратно к обычному EOA-аккаунту.

После нажатия подтверждения дождитесь включения транзакции в блок. Успешное включение означает, что пользователь успешно переключился со смарт-аккаунта обратно на обычный EOA-аккаунт. Детальную информацию о транзакции также можно найти на странице текущего адреса кошелька в etherscan.

2. Пример фишинговой атаки на 7702

24 мая группа злоумышленников #InfernoDrainer использовала функцию пакетного выполнения контракта MetaMask 7702-Delagator для массового получения авторизаций токенов у пользователя (0xc6D2…06DC) и осуществила фишинговую атаку, нанеся ущерб свыше 146 тыс. долларов США в виде $HashAI $HUMANS $ParallelAI $NeuralAI $DSync $Zero1 $NodeAI $Sensay $Virtual.

• Адреса мошенников

0x0000db5c8B030ae20308ac975898E09741e70000 0x00008C22F9F6f3101533f520e229BbB54Be90000 0xa85d90B8Febc092E11E75Bf8F93a7090E2ed04DE 0xC83De81A2aa92640D8d68ddf3Fc6b4B853D77359 0x33dAD2bbb03Dca73a3d92FC2413A1F8D09c34181

• Пример фишинговой транзакции

https://etherscan.io/tx/0x09c264618e93983510aaeb7aa2c91c8254a8b2ec66167438f3f6c28b866b6eba

• Причины успешной фишинговой атаки

Пользователь (0xc6D2…06DC) выполнил вредоносную транзакцию пакетной авторизации:

Хеш транзакции Ethereum: 0x1ddc8cecbc... | Etherscan

Вызов метода 0xe9ae5c53 От 0xc6D289d5...0d2E606DC к 0xc6D289d5...0d2E606DC | Успех | 23-мая-2025 14:31:35 (UTC)

etherscan.io

• Группы #InfernoDrainer и #PinkDrainer экспериментируют с более скрытными и масштабными схемами фишинга на базе 7702 в теневой индустрии.

Согласно нашим исследованиям, на данный момент черные рынки фишинга #InfernoDrainer и #PinkDrainer активно изучают и тестируют еще более скрытные и влиятельные схемы эксплуатации 7702 для фишинговых атак. Соответствующие адреса приведены ниже, мы также подготовим и опубликуем подробный отчет в будущем:

Inferno Drainer:

0x0000db5c8B030ae20308ac975898E09741e70000

Pink Drainer:

0xe49e04F40C272F405eCB9a668a73EEAD4b3B5624

3. Рекомендации по безопасности

Для поставщиков кошельков:

• Ориентируясь на реализацию и управление безопасностью 702 Delagator в MetaMask, запретите пользователям предоставлять авторизацию любым произвольным делегатам и разрешайте выполнение таких операций только внутри приложения. Предупреждайте пользователей о том, что любые попытки заманить их на страницу веб-сайта для подписания авторизации являются фишинговыми атаками.

• Проверяйте соответствие сети текущему подключению и предупреждайте пользователей о рисках атак повторного воспроизведения (replay attack) при использовании подписи с chainID равным 0.

• Показывайте целевой контракт при подписании авторизации пользователем и отображайте конкретное содержимое вызовов функций при пакетном выполнении через делегата, чтобы снизить риск фишинговых атак.

Для пользователей:

• Защита приватного ключа всегда остается приоритетом. Not your keys, not your coins.

• Не предоставляйте авторизацию делегатам на основе любых независимых веб-страниц. Безопасная авторизация, как правило, осуществляется только внутри приложения, аналогично тому, как это делает MetaMask.

• При использовании любого кошелька для подписания внимательно изучайте содержимое подписи, чтобы избежать слепого или ошибочного подписания документов.