Инцидент безопасности Binance привлек внимание не только из-за масштаба подозрительной активности кошельков, но и из-за одной технической детали, заметной незадолго до того, как крупные активы Ethereum начали перемещаться: пакет авторизаций EIP-7702.
Эта деталь быстро выдвинула EIP-7702 в центр обсуждения. Механизм делегирования аккаунтов Ethereum позволяет обычному внешне принадлежащему аккаунту, или EOA, временно выполнять логику смарт-контракта. В инциденте с Binance исследователи блокчейна выявили делегирование EIP-7702 незадолго до того, как активы были переведены с горячего кошелька, связанного с Binance.
Но здесь есть важное различие.
Наличие авторизации EIP-7702 само по себе не доказывает, что EIP-7702 был использован в качестве уязвимости.
Первоначальное расследование Binance вместо этого указывает на компрометацию операционной инфраструктуры. Биржа заявила, что ноутбук инженера DevOps мог быть скомпрометирован, что позволило злоумышленнику получить доступ к сервисному контейнеру и отправить несанкционированные транзакции на вывод средств. Binance также заявила, что не нашла доказательств утечки приватных ключей кошельков.
Это делает инцидент особенно важным для понимания современной безопасности кошельков. Приватный ключ может оставаться внутри защищенной инфраструктуры, пока злоумышленник злоупотребляет другой системой, которой разрешено запрашивать легитимные подписи.
В этой статье объясняется, что, по-видимому, сделал EIP-7702 в ходе инцидента, почему сообщения о множественных авторизациях привлекли внимание и почему различие между кражей ключей и компрометацией инфраструктуры подписывания имеет значение.
Что произошло в инциденте безопасности Binance?
Подозрительная активность, связанная с горячими кошельками Binance, начала привлекать внимание 30 октября 2026 года.
Исследователи ончейн-данных наблюдали крупные переводы с кошельков, связанных с биржей, на недавно созданные адреса. Ранние оценки существенно различались, поскольку исследователи отслеживали транзакции в Ethereum, Bitcoin, Tron и других сетях.
Впоследствии Binance признала инцидент безопасности и начала расследование источника несанкционированных транзакций. Биржа временно приостановила депозиты и выводы средств, проводя проверки безопасности.
В своем обновлении по безопасности от 30 октября Binance заявила, что первоначальное расследование показало: скомпрометированный ноутбук инженера DevOps позволил злоумышленнику получить доступ к сервисному контейнеру и отправить несанкционированные транзакции на вывод средств.
Биржа оценила общий ущерб примерно в 6,3 миллиарда долларов на том этапе расследования и заявила, что около 3 миллиардов долларов затронутых активов было заморожено ончейн. Binance также заявила, что покроет убытки за счет своего фонда SAFU и средств компании.
Что наиболее важно для технического обсуждения, Binance заявила:
Она не нашла доказательств утечки приватного ключа кошелька.
Это заявление меняет то, как следует интерпретировать сообщения об активности EIP-7702.
Вместо того чтобы спрашивать только, украл ли злоумышленник приватный ключ горячего кошелька, более актуальным становится вопрос, могла ли скомпрометированная внутренняя система запросить или способствовать получению действительной авторизации от защищенной инфраструктуры подписывания.
Почему EIP-7702 стал частью расследования?
EIP-7702 был введен вместе с обновлением Ethereum Pectra, чтобы предоставить внешне принадлежащим аккаунтам некоторые возможности, обычно связанные со смарт-контрактными кошельками.
Традиционно Ethereum EOA контролируется приватным ключом. Он может подписывать транзакции, переводить активы и взаимодействовать со смарт-контрактами, но его собственный аккаунт не содержит программируемой логики исполнения.
EIP-7702 меняет это соотношение.
Он позволяет EOA авторизовать код другого контракта для выполнения роли своей логики исполнения, сохраняя при этом исходный адрес Ethereum.
Это обеспечивает полезные функции абстракции аккаунта, такие как пакетирование транзакций, спонсирование газа и более продвинутые системы разрешений.
Это также означает, что авторизация EIP-7702 заслуживает существенно большего внимания, чем обычное одобрение токенов.
В ходе анализа инцидента с Binance исследователи сообщили, что адрес, пополненный через Tornado Cash, отправил несколько авторизаций EIP-7702, связанных с горячим кошельком Ethereum, связанным с Binance, незадолго до того, как произошли крупные переводы активов.
Одна авторизация, как сообщается, соответствовала состоянию кошелька и вступила в силу.
Примерно через три минуты значительные активы начали покидать кошелек.
Время естественным образом сделало авторизацию важной частью расследования.
Но это все еще не говорит нам, как была получена действительная авторизация.
Как работает авторизация EIP-7702?
Самый простой способ понять механизм — представить, что EIP-7702 позволяет обычному аккаунту Ethereum временно заявить:
«Используй логику выполнения этого смарт-контракта, когда мой аккаунт получает вызовы».
Упрощённая схема выглядит так:
Ethereum EOA
│
│ Подписывает авторизацию EIP-7702
▼
Делегирование назначено
│
▼
Смарт-контракт-делегат
│
│ Предоставляет исполняемую логику
▼
Исходный EOA может выполнять
поведение в стиле смарт-контракта
Исходный аккаунт не исчезает.
Его адрес, балансы и существующая история в сети остаются неизменными. Меняется код, который может быть выполнен через этот аккаунт.
EIP-7702 также включает механизмы защиты. Авторизации привязаны к состоянию аккаунта, включая nonce, и могут быть заменены или отозваны. Таким образом, это не произвольные инструкции, которые кто угодно может прикрепить к чужому кошельку.
Действительная авторизация по-прежнему требует законной криптографической авторизации от соответствующего аккаунта.
Этот момент имеет центральное значение для понимания инцидента с Binance.
Если злоумышленнику успешно удаётся установить вредоносную логику делегирования, важный вопрос безопасности заключается не просто в том:
«Использовал ли злоумышленник EIP-7702?»
Он заключается в том:
«Как злоумышленник получил полномочия для создания действительной авторизации EIP-7702?»
Почему сообщалось о множественных авторизациях EIP-7702?
Исследователи безопасности, изучавшие транзакции, сообщили, что злоумышленник отправил пакет, содержащий примерно 50 авторизаций, связанных с различными значениями nonce.
На первый взгляд «50 авторизаций» может звучать так, будто были скомпрометированы 50 кошельков.
Это не обязательно то, что произошло.
Аккаунты Ethereum поддерживают nonce, который изменяется по мере выполнения транзакций. Авторизация EIP-7702 должна соответствовать соответствующему состоянию аккаунта.
Если злоумышленник знает, какой кошелёк он хочет атаковать, но не может надёжно определить, какой nonce будет действителен, когда транзакция достигнет сети, он может подготовить авторизации для нескольких возможных значений nonce.
Успешно пройдёт только авторизация, соответствующая действительному состоянию кошелька.
Этот метод иногда называют распылением nonce.
Важное следствие заключается в том, что наличие 50 записей авторизации не обязательно означает 50 успешных разрешений, 50 скомпрометированных приватных ключей или 50 отдельных атак на кошельки.
Вместо этого такая схема могла быть разработана для повышения вероятности того, что одна ранее полученная авторизация совпадёт с состоянием целевого аккаунта при отправке.
Это порождает ещё один вопрос:
Кто — или какая внутренняя система — имел полномочия создать лежащую в основе подпись?
Именно здесь предварительные выводы Binance становятся особенно актуальными.
Кража приватного ключа и компрометация инфраструктуры подписи — это разные проблемы
Многие обсуждения безопасности криптовалют сводят защиту кошелька к одному принципу:
Защитите приватный ключ.
Это остаётся essential, но институциональные кошельки значительно сложнее.
Биржа может использовать аппаратные модули безопасности, сервисы подписи, механизмы политик, сервисы вывода средств, системы контроля доступа и другую инфраструктуру вокруг базового ключа.
Поэтому злоумышленник может попытаться скомпрометировать процесс, который запрашивает подпись, вместо извлечения самого приватного ключа.
Предварительное расследование Binance в настоящее время указывает гораздо больше на второй сценарий.
Биржа заявила, что скомпрометированный ноутбук DevOps мог предоставить доступ к сервисному контейнеру, способному отправлять несанкционированные транзакции вывода средств, при этом явно указав, что не обнаружила доказательств утечки приватного ключа.
Это различие существенно.
Аппаратно защищённый приватный ключ технически может оставаться в безопасности, в то время как окружающая инфраструктура создаёт подпись для чего-то, что никогда не должно было быть одобрено.
Стал ли EIP-7702 причиной взлома Binance?
Основываясь на доступной в настоящее время информации, нет публичных доказательств того, что уязвимость в самом EIP-7702 стала причиной инцидента безопасности Binance.
Это различие критически важно.
Использование злоумышленником легитимной функции протокола не означает автоматически, что эта функция была скомпрометирована.
Рассмотрим более простой пример.
Если злоумышленник получает легитимные учётные данные для банковского счёта и инициирует перевод через обычную платёжную систему банка, тот факт, что банковская инфраструктура переводов выполнила платёж, не доказывает, что сам протокол перевода был дефектным.
Аналогичное различие применимо и здесь.
EIP-7702 мог предоставить механизм выполнения, посредством которого успешно авторизованный аккаунт мог делегировать своё поведение вредоносному коду.
Но EIP-7702 обычно требует действительной авторизации.
Нерешённый вопрос заключается в том, как эта авторизация стала возможной.
Предварительное объяснение Binance предполагает, что следователи изучают скомпрометированную операционную инфраструктуру, а не сбой протокола Ethereum.
Следовательно, наиболее точная интерпретация на данном этапе такова:
EIP-7702, по-видимому, имеет отношение к исследуемому пути выполнения, но не было установлено, что он является корневой уязвимостью.
Что было подтверждено и что остаётся предметом расследования?
Поскольку крупные инциденты безопасности развиваются стремительно, особенно важно отличать подтверждённые выводы от анализа на уровне транзакций.
Это различие имеет значение, поскольку транзакции блокчейна обеспечивают превосходную видимость того, что произошло в сети, но они не обязательно раскрывают, как была скомпрометирована внутренняя система подписи.
Исследователи могут наблюдать делегирования, переводы и взаимодействия с контрактами.
Они не могут определить только по данным блокчейна, была ли подпись создана после кражи закрытого ключа, запросила ли её легитимно внутренняя служба или скомпрометированный рабочий процесс заставил защищённый подписант авторизовать вредоносные инструкции.
Для этого требуются доказательства изнутри затронутой инфраструктуры.
Почему инфраструктура подписи так же важна, как и хранение закрытых ключей
Институциональная безопасность криптовалют всё чаще состоит из нескольких уровней.
Первый — это безопасность ключей.
Где хранится закрытый ключ? Можно ли его извлечь? Защищён ли он аппаратным модулем безопасности или другой криптографической системой хранения?
Второй — это безопасность подписи.
Какие службы имеют право запрашивать подписи у защищённого ключа? Каким механизмам аутентификации, политикам и процедурам утверждения должны соответствовать эти службы?
Третий — это безопасность авторизации.
Даже если запрос криптографически действителен, что именно аккаунту предлагается авторизовать?
Этот третий уровень становится всё более важным по мере того, как смарт-аккаунты и делегирование аккаунтов становятся более функциональными.
Обычный перевод токенов может перемещать фиксированное количество одного актива.
Делегирование же может изменить то, как аккаунт может выполнять будущие инструкции.
Для команд безопасности это различие означает, что одной лишь проверки подписи уже недостаточно.
Необходимо также оценивать смысл транзакции.
Почему EIP-7702 меняет допущения о безопасности кошельков
EIP-7702 мощён именно потому, что расширяет возможности обычного аккаунта Ethereum.
Кошелёк может получить программируемые функции без миграции активов в совершенно новый смарт-контрактный кошелёк.
Для потребительских кошельков это может повысить удобство использования.
Для сложной институциональной инфраструктуры это может поддерживать более продвинутые политики выполнения.
Но дополнительная программируемость создаёт дополнительные поверхности авторизации.
Вредоносное одобрение ERC-20 обычно даёт другому адресу разрешение на один токен.
Вредоносное делегирование EIP-7702 потенциально может влиять на то, как аккаунт выполняет гораздо более широкие классы действий.
Это не делает EIP-7702 по своей сути небезопасным.
Это означает, что кошельки, биржи и кастодиальные провайдеры должны рассматривать авторизацию делегирования как операцию безопасности с высоким риском.
Подпись EIP-7702 не должна оцениваться только как криптографически действительная.
Системы безопасности также должны спрашивать, ожидаема ли цель делегирования, был ли проверен её байт-код, соответствует ли запрошенная авторизация обычному поведению аккаунта и позволяет ли внутренняя политика этому аккаунту делегировать выполнение вообще.
Что должен прояснить пост-мортем Binance?
Binance заявила, что подробный технический пост-мортем будет опубликован после завершения расследования.
Несколько вопросов определят, как индустрия в конечном итоге интерпретирует инцидент.
Во-первых, как злоумышленник получил доступ к пути подписи?
Предварительное объяснение DevOps указывает на потенциально скомпрометированную часть инфраструктуры, но полная цепочка от этого доступа до действительной блокчейн-авторизации остаётся важной.
Во-вторых, какую именно роль сыграл EIP-7702?
Следователям необходимо будет определить, требовалась ли делегация для выполнения переводов Ethereum, как была подготовлена авторизация и почему внутренние механизмы контроля допустили это.
В-третьих, были ли когда-либо скомпрометированы приватные ключи?
В настоящее время Binance заявляет, что нет доказательств утечки приватных ключей. Полный криминалистический отчёт мог бы предоставить больше деталей о том, как ключи были изолированы от скомпрометированной инфраструктуры.
Наконец, какой механизм контроля должен был остановить транзакцию?
Для институциональных команд безопасности это может быть самым ценным вопросом из всех.
Технически действительная подпись не должна автоматически означать операционно действительную транзакцию.
Самые надёжные системы кастодиального хранения отделяют криптографическую авторизацию от бизнес-авторизации.
Что это значит для обычных пользователей кошельков Ethereum?
Инцидент с Binance затрагивает институциональную инфраструктуру и не должен автоматически интерпретироваться как доказательство того, что обычные кошельки Ethereum подвержены тому же пути атаки.
Личный кошелёк с самостоятельным хранением и система горячего кошелька биржи работают совершенно по-разному.
Однако EIP-7702 преподносит важный урок и для отдельных пользователей:
Подпись делегации заслуживает такого же уровня осторожности, как и другие мощные разрешения кошелька.
Пользователи должны тщательно проверять, что кошелёк просит их подписать, особенно когда незнакомый веб-сайт запрашивает делегацию аккаунта.
Вредоносную делегацию не следует путать с обычной подписью для входа.
Пользователям также следует полагаться на проверенные интерфейсы кошельков, которые чётко идентифицируют запросы делегации и помечают подозрительные контракты.
Ключевой принцип безопасности остаётся простым: не судите о подписи только по тому, переводит ли она средства немедленно. Некоторые подписи изменяют то, что аккаунту будет разрешено делать впоследствии.
Более широкий урок: безопасность кошельков выходит за пределы приватных ключей
Инцидент безопасности Binance высвечивает более широкую эволюцию в безопасности блокчейна.
На протяжении многих лет доминирующее предположение индустрии было простым:
Защити ключ — защитишь кошелёк.
Эта модель становится неполной.
Современные институциональные кошельки часто зависят от слоёв инфраструктуры вокруг ключа — API, сервисов подписи, движков вывода средств, систем политик, механизмов контроля доступа и сред автоматизированного выполнения.
Механизмы абстракции аккаунта, такие как EIP-7702, добавляют ещё один слой, позволяя кошелькам делегировать логику выполнения.
В результате безопасность криптовалют всё больше зависит от трёх отдельных вопросов:
Кто контролирует ключ?
Кто может запросить подпись?
И какие полномочия эта подпись фактически предоставляет?
Система может преуспеть в первом вопросе, но потерпеть неудачу во втором или третьем.
Похоже, это один из наиболее важных вопросов, поднятых расследованием Binance на данный момент.
Часто задаваемые вопросы
Был ли EIP-7702 причиной взлома Binance?
Не подтверждено. Предварительные выводы Binance указывают на скомпрометированную операционную инфраструктуру, тогда как EIP-7702, по-видимому, был частью пути авторизации, находящегося под расследованием.
Были ли украдены приватные ключи Binance?
Binance заявила, что в ходе первоначального расследования не обнаружила доказательств утечки приватных ключей кошелька.
Что такое EIP-7702?
EIP-7702 позволяет EOA Ethereum делегировать логику выполнения смарт-контрактному коду, сохраняя тот же адрес кошелька.
Почему наблюдалось несколько авторизаций EIP-7702?
Они могли быть подготовлены с разными значениями nonce для соответствия целевому состоянию аккаунта. Это не обязательно означает, что несколько кошельков были скомпрометированы.
Затронуты ли обычные пользователи Ethereum?
Нет доказательств компрометации кошельков Ethereum в масштабах всей сети. Пользователям всё же следует проявлять осторожность с незнакомыми запросами делегации или подписи.
Достаточно ли отозвать разрешения на токены?
Не всегда. Разрешения ERC-20 и делегирование EIP-7702 — это отдельные разрешения, поэтому отзыв разрешения на токен не удаляет автоматически делегирование аккаунта.
Заключение
Появление EIP-7702 в инциденте с Binance делает этот механизм важной частью технического расследования, однако имеющиеся доказательства не устанавливают, что сам EIP-7702 был скомпрометирован.
Предварительные выводы Binance, напротив, предполагают, что злоумышленник мог скомпрометировать ноутбук DevOps-инженера, получить доступ к операционному контейнеру сервиса и отправить несанкционированные транзакции на вывод средств. Биржа заявляет, что не обнаружила доказательств утечки приватных ключей кошелька.
Это различие имеет значение.
Если защищённую систему подписи можно склонить к авторизации вредоносных инструкций, злоумышленникам может вообще не понадобиться красть приватный ключ.
EIP-7702 может усиливать последствия такой авторизации, поскольку позволяет аккаунту Ethereum делегировать программируемую логику исполнения. Но использовать эту возможность во вред и найти уязвимость в протоколе — это две разные вещи.
До тех пор, пока Binance не опубликует полный технический разбор инцидента, EIP-7702 лучше всего понимать как компонент описанного пути исполнения, а не как подтверждённую первопричину инцидента.
Для бирж, кастодиальных провайдеров и разработчиков кошельков более широкий урок уже очевиден: современная безопасность кошельков должна защищать не только приватные ключи, но и системы, запрашивающие подписи, а также разрешения, которые эти подписи создают.
Отказ от ответственности за риски: Эта статья предназначена исключительно для информационных и образовательных целей. Криптовалюты и блокчейн-системы связаны с техническими, операционными и рыночными рисками. Читателям следует самостоятельно проверять информацию о безопасности и применять надлежащие меры контроля рисков при управлении цифровыми активами.
