Назад

2026/11/03

Как одна подпись раз за разом опустошала горячий кошелёк Binance: делегирование EIP-7702 за взломом

50 заранее подписанных авторизаций EIP-7702, одно совпадение и делегирование, пережившее пустой кошелёк. Как это работало и что отслеживать операторам.

В нашей первой статье о взломе Binance мы рассмотрели, с чего, по имеющимся данным, началась атака: со скомпрометированного ноутбука DevOps-инженера и злоумышленников, добравшихся до систем, которые подтверждают критически важные действия. С тех пор ончейн-анализ компании по безопасности Blockaid показал, как была реализована заключительная стадия в Ethereum. В ней использовался EIP-7702 — функция, добавленная в Ethereum в мае 2025 года, — и она демонстрирует риск, который многие операторы горячих кошельков ещё не учли в своих планах.

Если коротко: одна подписанная авторизация превратила крупнейший горячий кошелёк Binance в Ethereum в аккаунт, которым мог управлять злоумышленник. Этот контроль не прекратился, когда кошелёк опустел, и не прекратился бы даже после смены ключа.

Главное

  • Злоумышленник поместил в одну транзакцию 50 заранее подписанных авторизаций EIP-7702 для 50 последовательных nonce; ровно одна из них совпала и передала исполнение кошелька контракту злоумышленника.
  • Делегирование EIP-7702 действует, пока аккаунт сам не заменит или не отменит его. Средства, поступившие после первого вывода, — в какой-то момент более 200 миллионов долларов — были похищены без какой-либо новой подписи.
  • Смена закрытого ключа не снимает делегирование, потому что оно принадлежит адресу. Снять его можно только явным отзывом.
  • Как злоумышленник получил 50 действительных подписей, пока неизвестно. Binance заявляет, что не нашла признаков утечки закрытого ключа.
  • Операторам горячих кошельков следует отслеживать состояние делегирования, отказываться подписывать незапланированные авторизации и включить явный отзыв в регламенты реагирования на инциденты.

Кратко о EIP-7702

EIP-7702 позволяет обычному аккаунту Ethereum (внешнему аккаунту, EOA) делегировать своё исполнение смарт-контракту. Владелец аккаунта подписывает авторизацию, в которой указаны адрес контракта, сеть и текущий nonce аккаунта. После обработки транзакции с такой авторизацией вызовы аккаунта выполняют код контракта, как если бы аккаунт был смарт-контрактным кошельком. Функция существует для легитимных целей, например для пакетной обработки транзакций и оплаты комиссий за пользователя.

Для этого инцидента важны три детали спецификации:

  • Авторизации передаются в новом типе транзакций — типе 4 (0x04), который может содержать их список. Отправить такую транзакцию может кто угодно; авторизации нужна лишь действительная подпись аккаунта.
  • Каждая авторизация действительна, только если её nonce равен текущему nonce аккаунта. Если он не совпадает, пропускается только эта авторизация, а транзакция переходит к следующей.
  • Делегирование постоянно. Оно сохраняется, пока аккаунт не подпишет новую авторизацию, указывающую на другой контракт, или авторизацию, указывающую на нулевой адрес, которая его снимает.

Как был захвачен кошелёк Binance 14

Горячий кошелёк загруженной биржи постоянно отправляет транзакции, поэтому его nonce всё время меняется. Злоумышленник, заранее готовящий подписанную авторизацию, не может знать, какой nonce будет текущим в момент попадания транзакции в блок. Согласно анализу Blockaid, злоумышленник решил эту задачу, подписав не одно значение, а целый диапазон.

Время (UTC, 29 октября)Что произошло
15:59Злоумышленник развёртывает контракт-«сборщик» (sweeper). Он не верифицирован, и вызывать его может только операторский адрес злоумышленника.
20:20:59Одна транзакция типа 4 содержит 50 авторизаций EIP-7702, все подписанные ключом горячего кошелька Binance 14, для 50 последовательных nonce. Ровно одна совпадает с текущим nonce кошелька, и кошелёк теперь делегирован сборщику.
20:24:23Один вызов сборщика выводит из кошелька около 167 464 ETH, 1,615 миллиарда USDT и десятки других токенов, оставляя 1 ETH на комиссии.
20:41Через всё ещё делегированный кошелёк выводится около 823 миллионов USDC с отдельного смарт-аккаунта, которым управлял Binance 14.
с 21:04 до 23:56По мере поступления новых средств кошелёк опустошается ещё четыре раза. Только в 21:44 без новой подписи похищено более 200 миллионов долларов свежих поступлений.
00:10 (30 октября)Делегирование отозвано, согласно хронологии Hypernative.

Эпизод с USDC показывает ещё один эффект. Делегированный аккаунт сохраняет все роли, которые у него есть в других контрактах: владельца, исполнителя, одобренного распорядителя средств. Тот, кто управляет его исполнением, может использовать их все.

Почему пустой кошелёк всё ещё был опасен

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

Именно это здесь и произошло. После первого вывода средства продолжали поступать на Binance 14 и снова выводились. Смена ключа не помогла бы: как указывает Blockaid, для снятия делегирования нужна новая авторизация от того же аккаунта, указывающая на нулевой адрес. Пока такой отзыв не обработан, адрес следует считать находящимся под контролем злоумышленника.

Совет: при инциденте сначала отзовите делегирование, затем меняйте ключи и пополняйте кошелёк. Остановите все автоматические процессы, отправляющие средства на затронутый адрес, пока не убедитесь, что делегирование снято.

Что пока остаётся невыясненным

Все 50 авторизаций содержали действительные подписи ключа Binance 14. Есть два общих объяснения, и публичные данные пока не позволяют выбрать между ними:

  • Ключ утёк, и злоумышленник подписал авторизации напрямую.
  • Инфраструктура подписания была использована злонамеренно: злоумышленник заставил собственные системы подписания Binance подписать выбранные им данные, так и не извлекая ключ.

Binance заявила, что не нашла признаков утечки закрытого ключа кошелька, и её расследование продолжается. Генеральный директор Blockaid сообщил Cointelegraph, что активность больше похожа на компрометацию инфраструктуры подписания, чем на утечку ключа, но это предварительная оценка со стороны. Пока Binance не опубликует разбор инцидента, мы считаем этот вопрос открытым.

Что делать, если вы управляете горячими кошельками

1. Отслеживайте состояние делегирования

У делегированного аккаунта есть код. Согласно EIP-7702, этот код — индикатор делегирования 0xef0100, за которым следует 20-байтовый адрес контракта, которому делегировано исполнение. У обычного EOA кода нет вовсе. Проверить любой адрес можно стандартным вызовом JSON-RPC:

curl -s -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYOUR_HOT_WALLET","latest"]}' \
  https://YOUR_RPC_ENDPOINT

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

2. Следите за транзакциями типа 4, связанными с вашими адресами

Транзакция, делегирующая ваш кошелёк, не обязательно отправляется с него. Её может отправить кто угодно, если она содержит действительную авторизацию, подписанную вашим ключом. Отслеживайте транзакции типа 4, в списке авторизаций которых есть подпись одного из ваших адресов, а не только транзакции, отправленные с них.

3. Ведите реестр делегирований

Для каждого адреса, которым вы управляете, зафиксируйте, должен ли он вообще быть делегирован и, если да, какому проверенному аудитом контракту. Любое делегирование вне этого списка — инцидент. Если вы не используете EIP-7702, ожидаемое состояние каждого горячего кошелька простое: кода нет.

4. Отклоняйте неожиданные авторизации на стороне подписания

У авторизации EIP-7702 собственный формат подписи: хеш байта 0x05, за которым следуют закодированные chain ID, адрес контракта и nonce. Сервисы подписания и политики HSM могут распознавать этот формат. Если вы не используете делегирование, полностью блокируйте такие данные; если используете, разрешайте только известные адреса контрактов. Учтите также, что авторизация с chain ID 0 действительна во всех сетях.

5. Включите явный отзыв в регламент реагирования на инциденты

Опишите, как отозвать делегирование для каждого кошелька: кто подписывает авторизацию на нулевой адрес, из какой системы и как вы убеждаетесь, что она вступила в силу (код адреса снова равен 0x). Включите в процедуру остановку входящих переводов на затронутый адрес и отработайте её заранее, до того как она понадобится.

Совет: та же идея применима и за пределами криптовалют. Любое предоставленное право, которое продолжает действовать дольше, чем создавшие его учётные данные, — например refresh-токен OAuth, делегированная облачная роль или долгоживущий токен CI/CD, — требует отдельного явного шага отзыва при реагировании на инциденты.

Чем может помочь LOGIQ

LOGIQ помогает организациям проверить, кто и что может действовать с полномочиями на их серверах Linux, в облачных аккаунтах и конвейерах, и выстроить мониторинг и процедуры реагирования на инциденты, которые охватывают делегированный доступ, а не только пароли и ключи. Если вы хотите ещё раз взглянуть на собственные меры контроля, прочитайте нашу первую статью о взломе (ссылка выше) или свяжитесь с нами через наш сайт.

Источники