Основатель Cardano, Чарльз Хоскинсон, предупредил об "крайне опасном коде", опубликовав анализ, который обвиняет функцию делегирования EIP-7702 в Ethereum в том, что она помогла злоумышленникам быстро опустошить горячий кошелек Binance.

В своем посте в X, Хоскинсон написал: "Будьте осторожны, в сети существует крайне опасный код", сопроводив это анализом, опубликованным CyberSatoshi.

В посте, который он распространил, описывается восстановленный байт-код предполагаемого "очистителя" (sweeper) EIP-7702 для Binance, утверждающего, что этот контракт был разработан специально для работы с инфраструктурой этой биржи. Сообщение Хоскинсона не указывало на конкретную уязвимость протокола и не объясняло, какую часть анализа он поддерживает.

Аккаунт CyberSatoshi ставит два вопроса безопасности рядом друг с другом. Первый касается того, как злоумышленник получил разрешение на действия от имени кошелька. Второй касается того, что функция делегирования Ethereum позволила злоумышленнику сделать после получения этого разрешения.

Вам также может быть интересно: Фонд Cardano присоединяется к швейцарской группе для поддержки токенизированных акций

Предполагаемый "очиститель" Binance обошел меры безопасности кошелька

Согласно анализу CyberSatoshi, восстановленный контракт оставил ровно 1 ETH в кошельке после "очистки" его баланса. Автор поста утверждал, что это предотвратило сбой автоматической системы обработки горячих кошельков Binance из-за недостаточного количества газа и, следовательно, предотвратило срабатывание тревог.

В анализе описывался цикл обработки токенов, который проверял балансы с помощью низкоуровневых вызовов и продолжал работу, даже если отдельные операции завершались неудачей. CyberSatoshi заявил, что это позволило "очистителю" продолжать обработку активов, даже если токен, внесенный в черный список или не отвечающий, не мог быть переведен.

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

CyberSatoshi охарактеризовал этот контракт как разработанный специально для архитектуры Binance. Утверждения о его влиянии на внутренние оповещения и системы управления активами являются объяснением автора поста о том, как работала эта операция.

EIP-7702 требует подписанного разрешения для делегирования

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

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

Каждая авторизация содержит информацию о цепочке, адресе делегата и nonce (случайном числе), а также криптографическую подпись. Протокол извлекает информацию об авторизующем аккаунте из этой подписи и проверяет его nonce, прежде чем применять делегирование.

Компания CyberSatoshi подтвердила это требование, заявив, что для предполагаемой атаки либо требовался исходный закрытый ключ, либо неограниченный доступ к инфраструктуре безопасности Binance 14.

В спецификации не указано, каким образом были получены какие-либо учетные данные для подписи от имени Binance. Однако требование наличия подписи подтверждает, что делегирование не может быть просто присвоено произвольному аккаунту без соответствующей авторизации.

Правила использования nonce в Ethereum объясняют предполагаемую массовую операцию

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

Спецификация обрабатывает авторизации в порядке их поступления. Если проверка авторизации не удалась, обработка продолжается со следующей записью. Успешная авторизация устанавливает делегирование и увеличивает nonce авторизующего аккаунта.

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

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

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

Документ, описывающий архитектуру Ethereum, указывает на риски, связанные с делегированием

Авторы EIP (Ethereum Improvement Proposal) прямо предупреждают, что авторизованный код имеет неограниченный доступ к аккаунту и должен быть тщательно проверен кошельком.

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

Делегирование сохраняется после транзакции, в которой оно было установлено. В спецификации также указано, что сбой выполнения не отменяет индикаторы делегирования, которые уже были обработаны.

Для удаления делегирования протокол позволяет использовать действительную авторизацию, указывающую на нулевой адрес, что очищает код делегирования аккаунта.