Хоскинсон поднимает вопрос о коде Binance sweeper на фоне растущих дебатов вокруг EIP-7702
Чарльз Хоскинсон поднимает тревогу по поводу потенциальных рисков EIP-7702, связывая его с недавней атакой на кошелек Binance. Узнайте больше о проблемах безопасности.

Обеспокоенность Чарльза Хоскинсона
Основатель Cardano, Чарльз Хоскинсон, выразил обеспокоенность по поводу "серьезно опасного кода", опубликовав анализ, который обвиняет функцию делегирования EIP-7702 Ethereum в том, что она помогла злоумышленникам быстро опустошить горячий кошелек Binance. В своем посте в X Хоскинсон написал:
"Будьте осторожны, существует серьезно опасный код", добавив к этому разбор, опубликованный CyberSatoshi.
Анализ CyberSatoshi
В этом разборе описывался восстановленный байт-код предполагаемого Binance EIP-7702 sweeper, утверждая, что контракт был адаптирован для операций биржи. Сопроводительное сообщение Хоскинсона не указывало на конкретный недостаток протокола и не объясняло, какую часть анализа он поддерживает.
Аккаунт CyberSatoshi ставит два вопроса безопасности рядом друг с другом. Один касается того, как злоумышленник получил разрешение действовать от имени кошелька. Другой касается того, что функция делегирования Ethereum позволила злоумышленнику сделать после получения этого разрешения.
Детали атаки
Согласно разбору CyberSatoshi, восстановленный контракт оставлял ровно 1 ETH в кошельке при опустошении его родного баланса. Постер утверждал, что это предотвратило сбой автоматической очереди горячего кошелька Binance из-за недостатка газа и поднятия тревоги. Анализ описывал цикл обработки токенов, который проверял балансы через низкоуровневые вызовы и продолжал работу, даже когда отдельные операции терпели неудачу.
CyberSatoshi заявил, что это позволило sweeper продолжать обработку активов, даже если токен был в черном списке или не отвечал. Предполагаемая пользовательская функция выполнения позволила скомпрометированному кошельку вызвать внешнее хранилище, содержащее 823 миллиона долларов в USDC.
Спецификация EIP-7702
Спецификация EIP-7702 описывает тип транзакции, который позволяет внешне управляемому аккаунту делегировать выполнение кода, развернутого по другому адресу. Внешне управляемый аккаунт обычно работает через подписи от своего закрытого ключа. Делегирование позволяет ему выполнять логику смарт-контракта в контексте своего собственного аккаунта, поддерживая такие функции, как объединение нескольких операций в одну транзакцию и позволяя другому аккаунту оплачивать транзакционные сборы.
Каждое разрешение идентифицирует цепочку, адрес делегата и nonce, вместе с криптографической подписью. Протокол восстанавливает авторизующий аккаунт из этой подписи и проверяет его nonce перед применением делегирования.
Уязвимости и последствия
CyberSatoshi признал это требование, заявив, что предполагаемая атака нуждалась либо в сыром закрытом ключе, либо в неограниченном доступе к подписи инфраструктуры безопасности Binance 14. Спецификация не устанавливает, как были получены какие-либо учетные данные для подписи Binance. Ее требование подписи устанавливает, что делегирование не может быть просто назначено произвольному жертвенному аккаунту без действительной авторизации.
CyberSatoshi утверждал, что злоумышленник представил 50 предварительно подписанных разрешений, охватывающих последовательные nonce, чтобы поймать Binance 14, пока его счетчик транзакций менялся.
Заключение
Спецификация обрабатывает разрешения в порядке. Когда разрешение не проходит проверку, обработка продолжается с следующей записи. Действительная запись устанавливает делегирование и увеличивает nonce авторизующего аккаунта. Таким образом, последовательные разрешения для одного и того же аккаунта могут стать действительными по мере продвижения этого nonce.
CyberSatoshi утверждал, что делегирование сжало передачи активов в одну операцию, сокращая время, доступное для вмешательства. Отдельное утверждение о том, что защитные механизмы биржи в противном случае остановили бы кражу после трех транзакций, является контрфактической оценкой постера.
Авторы EIP явно предупреждают, что авторизованный код имеет неограниченный доступ к аккаунту и должен быть тщательно проверен кошельком. Его раздел безопасности перечисляет защиты, необходимые для контрактов делегатов, включая предотвращение повторного использования и подписи, охватывающие стоимость транзакции, газ, назначение и данные вызова.
Плохо реализованное делегирование может оставить злоумышленника с почти полным контролем над подписывающим аккаунтом. Делегирование сохраняется за пределами транзакции, которая его устанавливает. Спецификация дополнительно утверждает, что сбой выполнения не откатывает индикаторы делегирования, которые уже были обработаны. Для удаления делегирования протокол допускает действительное разрешение, указывающее на нулевой адрес, что очищает код делегирования аккаунта.