Потеряно ~$15,9 млн: Trusted Volumes, Wasabi и другие | Еженедельный обзор BlockSec

За последние две недели (27.04.2026 - 10.05.2026) компания BlockSec выявила несколько инцидентов, связанных с атаками на различные блокчейн-экосистемы. В приведенной ниже таблице перечислены 11 значимых инцидентов с общим объемом предполагаемых убытков около $15,9 млн.

Три инцидента были отобраны для углубленного анализа на основе новизны атаки, финансового воздействия и последствий для безопасности:

• Aftermath Finance: реальный эксплойт бессрочных DEX-контрактов, где семантическое несоответствие между знаковыми и беззнаковыми типами данных при проверке комиссий привело к полному выводу средств протокола.
• Trusted Volumes: значительный финансовый ущерб (~$5.87 млн) и наглядная демонстрация ошибки авторизации в логике расчетов RFQ.
• Wasabi Protocol: компрометация инфраструктуры, повлекшая за собой контроль над контрактами, — класс атак, который становится все более распространенным, но недостаточно учитывается при аудите.

Событие недели: Aftermath Finance

Этот инцидент выделен, так как семантическое несоответствие между знаковыми и беззнаковыми числами — это тонкий класс уязвимостей, который выходит за рамки одного протокола. Любой DeFi-протокол, использующий библиотеку со знаком (fixed-point) для проверки беззнаковых значений комиссий или цен, подвержен такому же вектору атаки, что делает этот эксплойт важным уроком как для разработчиков, так и для аудиторов.

29 апреля 2026 года биржа бессрочных фьючерсов Aftermath Perpetuals на базе Sui подверглась эксплойту, в результате которого было украдено около $1,14 млн в USDC [1]. Первопричиной стало семантическое несоответствие при валидации комиссии сборщика (builder-fee): функция сравнения комиссий выполняла операции со знаковыми числами над беззнаковыми значениями. Это позволило злоумышленнику передать значение комиссии, которое при интерпретации со знаком становилось отрицательным. В процессе расчетов отрицательная комиссия преобразовывалась в положительный кредитный остаток обеспечения, позволяя атакующему вывести «раздутые» средства из хранилища протокола.

Предыстория

Aftermath Perpetuals — это ончейн-биржа бессрочных фьючерсов на Sui [2]. Протокол позволяет внешним интеграторам зарабатывать торговые комиссии за создание интерфейсов. Каждый интегратор устанавливает ставку комиссии (taker_fee), которая взимается с трейдеров. В качестве защиты трейдеры могут одобрять интеграторов, настраивая верхний предел ставки комиссии (maxTakerFee), который ограничивает размер комиссии.

При исполнении рыночного ордера протокол сначала сравнивает taker_fee с maxTakerFee, чтобы удостовериться, что комиссия находится в рамках, одобренных трейдером, а затем вычитает рассчитанную комиссию из обеспечения трейдера и записывает её на счет интегратора.

Арифметика протокола построена на библиотеке для работы с числами с фиксированной запятой (ifixed), которая представляет значения как целые числа u256, но интерпретирует их в формате «дополнительного кода» (two's-complement) для операций сравнения и арифметики.

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

Уязвимые контракты включают модуль интерфейса (0x9e2080...25d136) и модуль клиринговой палаты (0x21d001...7c5068).

Уязвимость кроется в функции calculate_taker_fees(), которая использует ifixed::less_than_eq() для сравнения taker_fee интегратора с maxTakerFee трейдера:

assert!(
    ifixed::less_than_eq(
        v5.taker_fee,
        account::get_integrator_max_taker_fee(
            account::get_integrator_config(arg1, v5.integrator_address)
        )
    ),
    errors::invalid_integrator_taker_fee()
);

Как taker_fee, так и maxTakerFee являются семантически неотрицательными ставками. Однако ifixed::less_than_eq() выполняет знаковое сравнение над u256. Когда maxTakerFee установлен в 0, значение, например 2^256 - 10^16, интерпретируется при знаковой семантике как -10^16. Поскольку условие -10^16 <= 0 выполняется, проверка проходит успешно.

Вектор атаки становится возможным, так как функция create_integrator_info() является публично доступной и не содержит проверок прав доступа или ограничений на передаваемое значение taker_fee:

public fun create_integrator_info(arg0: address, arg1: u256): Option<IntegratorInfo> {
    let v0 = IntegratorInfo {
        integrator_address : arg0,
        taker_fee          : arg1,
    };
    option::some<IntegratorInfo>(v0)
}

Отрицательная комиссия не просто принимается; она преобразуется в прямой положительный кредит обеспечения во время расчетов. В процессе расчетов обеспечение обновляется по формуле collateral += pnl - taker_fee - builder_fee. Когда builder_fee является отрицательным числом, вычитание превращается в сложение:

position::add_to_collateral_usd(
    arg0,
    ifixed::sub(v6, ifixed::add(v7, v8)),
    arg2
);

Ни проверка комиссии, ни арифметические расчеты не требуют, чтобы значения были неотрицательными, поэтому две отсутствующие проверки дополняют друг друга: знаковое сравнение «пропускает» отрицательное значение, а знаковая арифметика превращает его в добавочный кредит к обеспечению.

Анализ атаки

Следующий анализ основан на транзакции 4pGQdf...wVD8.

• Шаг 1: Атакующий разделил 100e6 USDC на два новых бессрочных счета: 1227 и 1228. Это создало изолированные контексты, позволяя атакующему выступать одновременно как мейкер (счет 1227) и тейкер (счет 1228).

• Шаг 2: Атакующий внес 100e6 USDC в качестве обеспечения на счет 1227 и открыл рыночную позицию, создав контрагента для будущего тейкер-ордера.

• Шаг 3: Атакующий создал хранилище интегратора, затем добавил конфигурацию к счету 1228 с maxTakerFee = 0. Установка лимита в ноль была критически важной: она заставляла знаковое сравнение taker_fee <= 0 принимать любое значение, которое выглядит отрицательным в дополнительном коде.

• Шаг 4: Атакующий начал сессию со счета 1227 и разместил лимитный ордер с order_size = 100e6, обеспечив ликвидность, с которой счет 1228 должен был торговать.

• Шаг 5: Атакующий вызвал create_integrator_info() со значением taker_fee = 2^256 - 100e6, что представляет -100e6 в семантике знаковых ifixed чисел. Поскольку функция публична и не выполняет проверок, вызов прошел успешно.

• Шаг 6: Атакующий выполнил рыночный ордер со счета 1228, используя вредоносные данные интегратора. Проверка комиссии прошла (-100e6 <= 0), и во время расчетов отрицательная комиссия была вычтена из обеспечения, что фактически добавило 100e6 свободного обеспечения на счет 1228.

• Шаг 7: Атакующий вывел «раздутое» обеспечение со счета 1228, получив 79 610 USDC. Атакующий повторял этот процесс в нескольких транзакциях, суммарно похитив около $1,14 млн.

Заключение

Этот инцидент был вызван семантическим несоответствием между знаковыми и беззнаковыми типами в проверке комиссий Aftermath Perpetuals. Основная проблема заключается в том, что функция сравнения (ifixed::less_than_eq) интерпретирует беззнаковые комиссии в знаковом формате. В сочетании с публичной функцией настройки комиссий без проверки границ, это позволило атакующему внедрить значение, которое проходит проверку как «отрицательное» и затем превращается в положительный актив.

Этот шаблон стоит запомнить: любой протокол, использующий библиотеку знаковых чисел с фиксированной запятой для проверки изначально неотрицательных значений (комиссий, цен, сумм), уязвим для такого типа атак. Меры защиты должны включать: (1) проверку на то, что значения комиссий неотрицательны, до любого сравнения (assert!(taker_fee >= 0)), (2) ограничение доступа к create_integrator_info() только авторизованными адресами и (3) использование беззнаковых функций сравнения для семантически беззнаковых величин.

Ссылки

• [1] Заявление Aftermath Finance после инцидента
• [2] Документация Aftermath Perpetuals
• [3] Builder Codes / Front-End Fee

Другие инциденты за этот период

Trusted Volumes

7 мая 2026 года прокси-контракт для кастомного RFQ (Request-For-Quote) в сети Ethereum был взломан, что привело к выводу около $5,87 млн у маркет-мейкера TrustedVolumes. Причиной стала ошибка авторизации в функции исполнения ордеров RFQ-контракта: проверка разрешений подписывающего лица и операция перевода токенов обращались к разным полям ордера, поэтому проверка авторизации проходила для одного адреса, а списание средств происходило с другого. Злоумышленник вывел около 1 291 WETH, 206 тыс. USDT, 16,94 WBTC и 1,27 млн USDC.

Предыстория

TrustedVolumes работает как маркет-мейкер в протоколе RFQ, развернутом в сети Ethereum. Маркет-мейкеры постоянно генерируют подписанные ценовые котировки вне сети; мейкеры (обычно трейдеры или агрегаторы) отправляют выбранную котировку в сеть, а протокол проверяет подпись и атомарно исполняет сделку, перемещая токены между мейкером и тейкером через transferFrom. Протокол не использует хранение средств: он никогда не берет активы на баланс. Каждый мейкер заранее выдает контракту протокола разрешение (ERC-20 allowance) для всех токенов, которые планирует котировать, и протокол списывает токены прямо с кошелька мейкера в момент исполнения.

Чтобы позволить маркет-мейкерам делегировать подпись горячим кошелькам, протокол ведет реестр подписывающих лиц для каждого мейкера. Мейкер может вызвать registerAllowedOrderSigner(signer, allowed), чтобы внести горячий ключ в «белый список», и любой последующий ордер, подписанный этим ключом, считается валидным.

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

Прокси-контракт RFQ развернут по адресу 0xeEeEEe...051756, а контракт реализации — 0x88eb28...2760d8.

Функция исполнения ордера 0x4112e1c2() в контракте реализации RFQ восстанавливает адрес подписчика через ecrecover() и проверяет allowedOrderSigner для решения о принятии подписи. Ключом поиска для этой проверки является varg4 — адрес тейкера в ордере. Однако последующий transferFrom, списывающий средства, использует varg5 — поле мейкера в ордере. Поскольку varg4 и varg5 являются независимыми полями структуры ордера, проверка авторизации и движение средств относятся к разным лицам. Нет проверки, гарантирующей, что домен авторизованного подписчика совпадает с адресом, с которого действительно списываются токены.

Функция registerAllowedOrderSigner записывает «белый список», используя msg.sender как внешний ключ, в то время как путь исполнения читает данные, используя varg4 в качестве ключа. Пока субъект, указанный в varg4, ранее зарегистрировал себя через registerAllowedOrderSigner, проверка авторизации проходит успешно, независимо от того, какой сторонний адрес указан в поле мейкера varg5.

Анализ атаки

Следующий анализ основан на транзакции 0xc5c61b...990513.

• Шаг 1: Атакующий развернул контракт атаки и вызвал через него registerAllowedOrderSigner, добавив свой EOA в «белый список» допущенных подписчиков. Это гарантировало, что ордера, подписанные атакующим, пройдут проверку авторизации протоколом.

• Шаг 2: Контракт атаки получил 4 вей USDC с EOA атакующего и одобрил их для RFQ-протокола, обеспечив минимально необходимый объем для выступления в роли тейкера.

• Шаг 3: Атакующий сфальсифицировал четыре ордера, каждый из которых был подписан EOA атакующего и называл TrustedVolumes в качестве мейкера. Поскольку проверка подписи смотрела на varg4 (контракт атакующего), в то время как transferFrom списывал средства с varg5 (TrustedVolumes), каждый ордер выводил деньги из TrustedVolumes. Четыре ордера обменяли 1 вей USDC на 1 291 WETH, 206 282 USDT, 16,939 WBTC и 1 268 771 USDC соответственно, общая прибыль составила около $5,87 млн.

Заключение

Основной дефект — несоответствие авторизации в функции исполнения ордера: адрес, используемый для проверки разрешений, отличается от того адреса, который реально платит. Конкретно: registerAllowedOrderSigner пишет данные под msg.sender, путь исполнения читает их по полю тейкера (varg4), а transferFrom списывает с поля мейкера (varg5). Поскольку эти три операции ссылаются на разные адреса, любой атакующий, зарегистрировавший свой ключ, может подделывать ордера для кражи средств любого мейкера. Проверки авторизации, контролирующие перевод активов, должны быть строго привязаны к адресу, который фактически платит, а пути записи и чтения должны использовать один и тот же ключ.

Wasabi Protocol

30 апреля 2026 года протокол Wasabi, предлагающий опционы и бессрочные фьючерсы и развернутый в нескольких EVM-сетях, подвергся инциденту безопасности с убытками около $5,7 млн ($4,8 млн средств пользователей, $900 тыс. из казны Wasabi) [1][2]. Атака возникла из-за компрометации инфраструктуры: открытая конечная точка аналитики на публичном сервере допустила утечку учетных данных, что в конечном итоге привело к краже приватных ключей, контролирующих EVM-контракты протокола. Используя эти ключи, нападавший выполнил несанкционированные выводы средств из нескольких хранилищ Wasabi в сетях Ethereum, Base, Blast и Berachain.

Предыстория

Wasabi Protocol развернут в сетях EVM (Ethereum, Base, Blast, Berachain) и Solana. Инцидент затронул только EVM-часть протокола; развертывания на Solana и Prop AMM не пострадали.

EVM-контракты Wasabi (WasabiLongPool, WasabiShortPool, WasabiVault) администрируются через привилегированные ключи. Протокол также использует внесетевую инфраструктуру, включая сервисы аналитики и мониторинга на базе Spring Boot.

Анализ атаки

Инцидент развивался по цепочке компрометации инфраструктуры до контроля над контрактами:

• Шаг 1: Атакующий обнаружил, что Spring Boot Actuator установлен на публично доступном сервере Wasabi. Дампы кучи (heap dumps) в Actuator обычно защищены паролем, но этот сервер использовал другой вариант фреймворка Spring, несовместимый со стандартным механизмом защиты, что оставило конечную точку дампа открытой.

• Шаг 2: Атакующий извлек дамп кучи, который содержал учетные данные для отдельного внутреннего сервера.

• Шаг 3: Используя украденные данные, атакующий получил доступ к внутреннему серверу и завладел приватными ключами, контролирующими EVM-контракты Wasabi.

• Шаг 4: Получив привилегированные ключи, атакующий выполнил несанкционированные операции вывода средств из контрактов WasabiLongPool, WasabiShortPool и WasabiVault во всех затронутых сетях, похитив в общей сложности около $5,7 млн.

Заключение

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

Ссылки

• [1] Оповещение BlockSec Phalcon
• [2] Заявление Wasabi Protocol после инцидента

О компании BlockSec

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

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

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

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

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

• 🔗 Phalcon Security APP: Записаться на демо

• 🔗 Phalcon Compliance