Баг ZetaChain был обнаружен White Hat-специалистом, назван "ожидаемым" и впоследствии привел к эксплойту на $334 000
Баг ZetaChain был обнаружен White Hat-специалистом, назван "ожидаемым" и впоследствии привел к эксплойту на $334 000
В конце апреля 2026 года межсетевая инфраструктура снова доказала, как незначительные проектные допущения могут привести к колоссальным рискам. ZetaChain подтвердила, что злоумышленник вывел около $334 000 из контролируемых протоколом кошельков, используя цепочку уязвимостей, охватывающую инициализацию сообщений, правила исполнения на целевой цепочке и долгосрочные разрешения ERC-20. Средства пользователей не пострадали, но инцидент является суровым напоминанием: в межсетевых системах "низкорисковые" компоненты редко остаются таковыми при взаимодействии.
Что делает этот случай особенно поучительным, так это сбой процесса, стоящий за техническим сбоем. ZetaChain признала, что основная проблема была ранее сообщена через канал программы поиска ошибок, однако первоначально была расценена как ожидаемое поведение, а не как нечто, требующее смягчения или более строгих ограничений. Обзор раскрытия информации и деталей после инцидента можно найти в материалах, таких как обзор Cointelegraph о проигнорированном отчете и последующем эксплойте: ZetaChain проигнорировала отчет об ошибке, которая могла предотвратить эксплойт.
Ниже представлен упрощенный для операторов обзор того, что произошло, почему путь эксплойта оказался успешным, что изменила ZetaChain и какие выводы должны сделать разработчики и пользователи в 2026 году, когда межсетевая активность шире, чем когда-либо, а наборы инструментов злоумышленников все чаще становятся "мультивекторными по умолчанию".
Краткий обзор инцидента: межсетевой технический долг взял свое
Действия злоумышленника в конечном итоге привели к 9 транзакциям в Ethereum, Arbitrum, Base и BNB Smart Chain, а украденные активы были выведены из кошельков, контролируемых ZetaChain, а не конечных пользователей. ZetaChain приостановила межсетевые операции до устранения проблемы; первоначальная остановка была широко освещена, когда инцидент впервые стал публичным (см.: Отчет The Block о приостановке и мерах по устранению).
Хотя сумма в долларах не была сопоставима с "мега-взломами мостов", важен сам шаблон: межсетевой шлюз, на который можно повлиять, чтобы инициировать подписанные протоколом вызовы на внешних цепочках, является мишенью с высоким рычагом воздействия, даже если непосредственный набор жертв ограничен.
Неутешительный урок: "ожидаемое поведение" может быть эксплуатируемым
Программы поиска ошибок предназначены для превращения враждебного любопытства в защитное совершенствование, но только в том случае, если триаж построен с учетом риска композиционности.
ZetaChain ранее запустила свою программу поиска ошибок в партнерстве с Immunefi (справка: Анонс программы поиска ошибок ZetaChain). Тем не менее, этот инцидент подчеркивает повторяющуюся отраслевую проблему: отчет может быть "правильным", даже если каждый отдельный компонент в изоляции выглядит некритичным. Сама Immunefi подчеркивает, что реальное воздействие и определение масштаба имеют значение (см.: Руководство Immunefi по правилам программы и воздействию).
Для межсетевых протоколов планка должна быть выше: если функция позволяет любой путь к "протокол может быть обманут и подписать что-то, что не должен", то она заслуживает многоуровневой защиты, даже если функция технически работает в соответствии с дизайном.
Как три "маленьких" проблемы слились в один большой эксплойт
Подробный технический анализ потока вызовов и поведения контрактов был опубликован независимыми исследователями; один из самых четких пошаговых анализов: Анализ взлома шлюза ZetaChain.
С точки зрения безопасности проектирования, цепочка эксплойта может быть сведена к трем звеньям:
1) Разрешение на бесконтрольное инициирование межсетевых инструкций на уровне шлюза
Одной из основных проблем было то, что путь на стороне шлюза мог быть вызван таким образом, что позволял злоумышленнику внедрять межсетевые намерения (т.е. "отправить это сообщение/вызов на целевую цепочку") без того, чтобы система применяла ожидаемую границу доверия к тому, кто имеет право инициировать такие инструкции.
В межсетевых системах то, кто может подать сигнал "это должно быть выполнено удаленно", является первой и самой важной линией обороны.
2) Правила исполнения на стороне получателя, которые были слишком разрешительными (и слишком полагались на узкий черный список)
На принимающей стороне путь выполнения позволял вызовы, которые были по сути "произвольными", с ограничениями, которые были недостаточно широкими, чтобы блокировать опасные операции с токенами. Черный список, блокирующий только пару селекторов, редко бывает достаточным, когда поверхность EVM огромна, а злоумышленникам нужен только один разрешенный примитив (например, transferFrom), чтобы монетизировать систему.
Это распространенная форма сбоя: черные списки устаревают в агрессивной среде.
3) Устаревшие разрешения ERC-20 превратили "исполнение" в "перемещение активов"
Последним звеном была операционная, а не чисто кодовая проблема: некоторые кошельки поддерживали неограниченные одобрения (или иначе чрезмерные разрешения) для контракта шлюза и не отзывали их после того, как они перестали быть необходимыми.
В ERC-20 разрешение — это, по сути, постоянное разрешение. Как только контракт получает возможность совершать вызов токена от своего имени, любое оставшееся разрешение становится заряженным оружием. Для контекста о том, как работают одобрения на стандартном уровне, см.: Документация OpenZeppelin по ERC-20.
Исследования также показали, насколько широко распространены неограниченные одобрения и почему они создают системный риск, выходящий далеко за пределы одного протокола (см.: Исследование риска одобрений "Скупой платит дважды").
Тактика злоумышленника: не случайность, а подготовка
ZetaChain описала эксплойт как имеющий явные признаки планирования, в том числе:
- Предварительное финансирование через Tornado Cash за несколько дней
- Развертывание выделенного контракта-"сливщика"
- Проведение кампании по отравлению адресов
Отравление адресов заслуживает особого внимания, поскольку оно все чаще смешивается с более широкими операциями эксплойта, не только как мошенничество для розничных пользователей, но и как способ создать путаницу во время реагирования на инциденты. Если вам нужен строгий обзор этой техники и того, почему она так часто работает, исследователи Университета Карнеги — Меллона поддерживают посвященный ей ресурс здесь: Обзор отравления адресов в блокчейне.
Что изменила ZetaChain: устранение "опасных" функций, а не просто исправление ошибок
Исправления после инцидента имеют наибольшее значение, когда они снижают классовый риск, а не просто блокируют один наблюдаемый полезный груз. Основываясь на раскрытом направлении исправления ZetaChain (как обобщено в общедоступных отчетах и технических анализах), ключевые изменения включают:
- Развертывание исправлений в основной инфраструктуре для закрытия эксплуатируемого пути.
- Постоянное отключение возможности произвольных вызовов, которая позволила получить результат "исполнить любые calldata, которые подписывает протокол".
- Замена неограниченных паттернов одобрения в потоках депозитов на одобрения точной суммы, чтобы одно одобрение не могло молча оставаться используемым спустя месяцы.
Самая важная тема — это переход от "мощной, но опасной общности" к "узким, проверяемым намерениям". Межсетевые протоколы, которые хотят безопасно масштабироваться в 2026 году, будут все чаще нуждаться в использовании списков разрешенных целей, типизированных сообщений и исполнения с ограниченными возможностями по умолчанию.
Выводы для разработчиков: безопасность межсетевых соединений в 2026 году — это композиция, а не компоненты
Даже за пределами ZetaChain межсетевые системы продолжают подвергаться атакам, поскольку они находятся на пересечении:
- сложных конечных автоматов,
- распределенного подписания/валидации,
- и высоко монетизируемых интерфейсов токенов.
Отраслевые отчеты об убытках продолжают показывать, что серьезность эксплойтов остается высокой, а события с хвоста риска доминируют в результатах (см. один пример агрегированного отраслевого отслеживания в: Отчет Immunefi "Crypto Losses in Q1 2025" (PDF)).
Если вы разрабатываете или интегрируете межсетевые сообщения, рассмотрите следующие практические меры предосторожности:
- Сделайте инициирование сообщения явным и аутентифицированным: "Любой может запросить межсетевой вызов" никогда не должно быть равносильно "протокол подпишет и выполнит его".
- Избегайте черных списков для исполнительных "приемников": предпочтите списки разрешенных целей и минимальные интерфейсы.
- Рассматривайте одобрения как часть вашей модели угроз: кошельки казначейства/операторов должны иметь строгие политики одобрения, мониторинг и периодическую очистку.
- Планируйте экстренную координацию: сети реагирования на инциденты, такие как SEAL 911, существуют, потому что минуты имеют значение, когда речь идет о подписях и межсетевом исполнении.
Чек-лист для пользователей: что делать после любого межсетевого инцидента (даже если "пользователи не пострадали")
Даже когда протокол заявляет, что средства пользователей не пострадали, разумно потратить 10 минут, чтобы уменьшить свой личный радиус поражения, особенно если вы когда-либо взаимодействовали с затронутыми контрактами шлюза.
1) Отозвать ненужные одобрения
Два надежных варианта:
- Используйте инструмент управления одобрениями, такой как Руководство по одобрениям токенов Revoke.cash
- Или используйте встроенный в блокчейн-обозреватель чекер, такой как Проверка одобрений токенов Etherscan
2) Защита от отравления адресов в повседневном поведении
- Не копируйте получателей из истории транзакций.
- По возможности используйте адресные книги / доверенные контакты.
- Проверяйте больше, чем первые/последние несколько символов — атаки с отравлением адресов разработаны так, чтобы совпадать с тем, что обрезают интерфейсы кошельков.
3) Используйте аппаратную верификацию адреса для высокоценных переводов
Аппаратный кошелек не может остановить ошибку смарт-контракта в протоколе, который вы не контролируете, но он может снизить вероятность того, что вы лично авторизуете неправильного получателя во время атаки с отравлением адреса или манипуляции с буфером обмена.
Именно здесь OneKey естественно вписывается: изолируя подписание и подчеркивая верификацию на устройстве, он помогает тому, "что вы подписываете", быть ближе к "тому, что вы намеревались" — особенно в стрессовых ситуациях, когда злоумышленники пытаются использовать путаницу.
Заключительные мысли
Эксплойт ZetaChain — это компактное практическое исследование современной реальности безопасности криптовалют:
- ранее сообщенная проблема,
- проигнорированная из-за предположения "по дизайну",
- в сочетании с разрешительным исполнением и оставшимися одобрениями,
- реализованная злоумышленником, который заранее подготовил финансирование, инструменты и шум на социальном уровне.
Если 2025–2026 годы чему-то научили индустрию, так это тому, что межсетевые системы должны проектироваться с учетом враждебной композиции. Самая безопасная функция — это та, которую вы не можете случайно превратить в оракула подписи, даже когда все "работает как ожидалось".
