Потери на $104.6 млн: Verus, RetoSwap и другие | Еженедельный отчет BlockSec

За прошедшую неделю (18.05.2026 – 24.05.2026) компания BlockSec зафиксировала несколько инцидентов, связанных с атаками в различных блокчейн-экосистемах. В таблице ниже представлены 5 наиболее серьезных инцидентов с суммарным оценочным ущербом около $104,6 млн.

Два инцидента были выбраны для углубленного анализа:

• Verus: злоумышленник использовал уязвимость проверки типов в кроссчейн-мосте Verus-Ethereum, отправив специально сформированный дополнительный экспортный вывод (supplemental export output), который мост ошибочно классифицировал как действительный первичный экспорт. Семантика кроссчейн-сообщений становится частью поверхности атаки.
• RetoSwap: ошибка аутентификации на уровне протокола в процессе P2P-торговли позволила злоумышленнику перехватить роль арбитра путем отправки поддельного сообщения ACK. Злоумышленник полностью скомпрометировал создание мультисиг-кошелька вне сети (off-chain).

Событие недели: Verus

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

18 мая 2026 года мост Verus-Ethereum, соединяющий блокчейн первого уровня Verus и Ethereum, подвергся атаке, в результате которой было выведено около $11,7 млн в ETH, tBTC и USDC [1][2]. Первопричиной стала ошибка проверки типов в пути импорта со стороны Ethereum: контракт моста принял специально сформированный дополнительный экспортный вывод и ошибочно классифицировал его как действительный первичный экспорт, что позволило злоумышленнику предоставить соответствующие данные о переводе и вывести средства. По состоянию на 23 мая около 75% похищенных средств было возвращено.

Предыстория

Мост Verus-Ethereum высвобождает активы в сети Ethereum после того, как доказано, что соответствующий экспорт в сети Verus существует в рамках нотариально заверенного состояния Verus. Ethereum не наблюдает за транзакциями Verus напрямую; он полагается на предоставленные данные доказательств и нотариальное заверение, которое фиксирует доверенное состояние Verus.

Для данного инцидента важны три объекта моста: первичный экспорт (primary export), объект, который Ethereum импортирует и использует для выплат; дополнительный экспортный вывод (supplemental export output), дополнительные данные, прикрепленные к первичному экспорту, которые не должны рассматриваться как самостоятельный активный экспорт для целей выплат; и нотариальное заверение (notarization), которое позволяет Ethereum доказать, что конкретный объект сети Verus существовал в итоговом состоянии моста.

Анализ уязвимости

Ошибочные контракты моста на стороне Ethereum развернуты по адресам 0xa045...6fc87f и 0x08f0...d0107d.

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

В общем виде уязвимый поток выглядит так:

proveImports(...)
    -> verify proof
    -> verify keccak256(serializedTransfers) == committed transfer hash

processTransactions(...)
    -> execute payouts on Ethereum

Ни одна проверка в этом потоке не отклоняет объекты с установленным флагом FLAG_SUPPLEMENTAL. Исправление явно проверяет этот флаг и прерывает выполнение, если доказанный объект является дополнительным:

Анализ атаки

Следующий анализ основан на транзакции в Ethereum 0x6990f0...87eb321 и транзакции в Verus f899e698...b9f5a733.

• Шаг 1: 17 мая злоумышленник пополнил адрес в Ethereum 0x5aBb...9D5777 на 1 ETH через Tornado Cash. 18 мая злоумышленник получил 0,02 VRSC из крана (faucet) Verus для адреса RW9vEW...B3g6zd.

• Шаг 2: Злоумышленник отправил четыре транзакции экспорта в сторону Ethereum в сети Verus, содержащие специально созданные дополнительные экспортные выводы. Эти выводы были закодированы так, чтобы их можно было проанализировать без ошибок, и содержали обязательство hashReserveTransfers, соответствующее мошенническим выплатам, которые злоумышленник планировал выполнить позже.

• Шаг 3: После того как кроссчейн-нотариальное заверение в Ethereum достигло нужного уровня, злоумышленник отправил поддельную транзакцию импорта в Ethereum. Доказанным объектом со стороны Verus был дополнительный вывод из транзакции Verus, указанной выше.

• Шаг 4: Мост Ethereum принял доказательство, но не отклонил доказанный объект как дополнительные данные. Вместо этого он проанализировал сформированный вывод так, как если бы это был действительный активный экспорт. Поскольку злоумышленник также предоставил serializedTransfers, хеш которых совпадал с зафиксированным значением hashReserveTransfers, мост продолжил выполнение потока импорта.

• Шаг 5: Поскольку дополнительный вывод был неверно истолкован как действительный экспорт, мошеннические переводы прошли проверки на стороне Ethereum. Злоумышленник вывел около $11,7 млн в ETH, tBTC и USDC.

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

Заключение

Инцидент был вызван ошибкой проверки типов в мосте Verus-Ethereum: контракт Ethereum принял реальное криптографическое доказательство, но доказанный объект был дополнительным экспортным выводом, а не действительным первичным экспортом для выплат.

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

Ссылки

• [1] Оповещение BlockSec Phalcon
• [2] Официальный пост-мортем Verus

Другие инциденты этой недели

RetoSwap

20 мая 2026 года RetoSwap, децентрализованная P2P-биржа на Monero, форкнутая из Haveno Protocol, подверглась атаке, в результате которой было похищено около $2,7 млн (7000 XMR) [1]. Первопричиной стала ошибка аутентификации на уровне протокола: клиент принял поддельное, внеочередное сообщение ACK и перезаписал сохраненный Tor-адрес арбитра на адрес, контролируемый злоумышленником, без проверки отправителя по известному открытому ключу арбитра. Это позволило злоумышленнику перехватить создание мультисиг-кошелька и украсть средства сразу после их внесения.

Предыстория

RetoSwap — это децентрализованная P2P-биржа на Monero, форкнутая из Haveno Protocol. Ее торговый протокол опирается на мультисиг-модель «2 из 3» с арбитром для обеспечения безопасности сделок и координирует сделки вне сети через Tor.

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

Анализ уязвимости

20 мая проект Haveno открыл пулл-реквест под названием "core: refuse to update node address before multisig created" [2]. К тому времени RetoSwap уже подвергался атаке.

Патч выявил уязвимость в TradeProtocol.java:onAckMessageAux(...). Клиент идентифицировал участников, используя senderNodeAddress, полученный из сообщения, не проверяя криптографически, что отправитель соответствует ожидаемому открытому ключу арбитра. Злоумышленник мог отправить поддельное сообщение ACK с адресом .onion, контролируемым злоумышленником, и клиент перезаписывал сохраненный адрес арбитра на него.

Поскольку это происходило во время Фазы 1 (до создания мультисиг-кошелька), адрес злоумышленника заменял адрес настоящего арбитра. Таким образом, злоумышленник удерживал ключ трейдера и ключ арбитра от мультисиг-кошелька, что позволяло совершить кражу всех средств сразу после их депозита.

Исправление решает проблему двумя способами: проверяет отправителя по известному открытому ключу узла, отклоняя сообщения от непроверенных участников; и ограничивает обновление адреса условием trade.isDepositRequested(), предотвращая перезапись до создания кошелька.

Анализ атаки

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

• Шаг 1: Злоумышленник присоединился к существующей сделке в качестве покупателя или продавца.

• Шаг 2: Злоумышленник отправил поддельное, внеочередное сообщение ACK, которое выглядело как исходящее от арбитра, с указанием контролируемого злоумышленником .onion адреса в качестве senderNodeAddress.

• Шаг 3: Клиент жертвы принял сообщение и перезаписал сохраненный адрес арбитра без проверки отправителя по известному открытому ключу арбитра.

• Шаг 4: Все последующие сообщения, предназначенные для арбитра, включая процесс создания мультисиг-кошелька, перенаправлялись злоумышленнику, который получал третий мультисиг-ключ.

• Шаг 5: Как только покупатель и продавец внесли средства в скомпрометированный мультисиг-кошелек, злоумышленник украл всё его содержимое. Общая прибыль составила около 7000 XMR (~$2,7 млн).

Заключение

Этот инцидент был связан не с криптографическим сбоем, а с ошибкой аутентификации на уровне протокола: сообщения проверялись на корректность формата, но отправитель не был криптографически привязан к известному открытому ключу до применения обновлений адреса. В результате клиент рассматривал непроверенный senderNodeAddress из поддельного сообщения ACK как новую точку связи арбитра до создания мультисиг-кошелька, что позволило злоумышленнику перехватить роль арбитра.

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

Ссылки

• [1] Заявление RetoSwap после инцидента
• [2] Пулл-реквест с исправлением Haveno

О компании BlockSec

BlockSec — поставщик услуг в области безопасности блокчейнов и крипто-комплаенса полного цикла. Мы создаем продукты и сервисы, которые помогают клиентам проводить аудит кода (включая смарт-контракты, блокчейны и кошельки), перехватывать атаки в реальном времени, анализировать инциденты, отслеживать незаконные средства и соблюдать требования AML/CFT на протяжении всего жизненного цикла протоколов и платформ.

BlockSec опубликовала множество исследований в области безопасности блокчейнов на престижных конференциях, сообщила о нескольких атаках «нулевого дня» в DeFi-приложениях, заблокировала многочисленные хакерские атаки, сохранив более 20 миллионов долларов, и обеспечила безопасность криптовалют на миллиарды долларов.

• Официальный сайт: https://blocksec.com/

• Официальный аккаунт в Twitter: https://twitter.com/BlockSecTeam

• 🔗 Аудиторский сервис BlockSec : Отправить запрос

• 🔗 Приложение Phalcon Security: Записаться на демонстрацию

• 🔗 Phalcon Compliance