25 июня 2026 года один злоумышленник провёл две атаки на два разных протокола в двух разных сетях — и в обоих случаях воспользовался тем, что контракты верили данным, которые следовало проверять строже. Суммарный ущерб составил около $24 тыс.
Введение
Lixir Finance — протокол управления ликвидностью на Ethereum, где пользователи вносят активы в vault-контракты (хранилища) и получают взамен vault-токены — своеобразные «квитанции», подтверждающие долю в хранилище. Ocean Protocol — децентрализованный рынок данных, работающий в том числе на Polygon, с пулами ликвидности на базе механизма BPool. Несмотря на совершенно разную природу проектов, атакующий нашёл слабое место в каждом из них.
Lixir Finance: поддельное разрешение от чужого имени
Сеть: Ethereum
Транзакция: 0x17026faca0b8e4cb7531e4fb277c390eb165e81229628e0192923ad1d90a41da
Что произошло
В Ethereum есть стандарт EIP-2612, который позволяет давать разрешения на управление токенами через подпись — без отдельной on-chain транзакции. Это удобно: вместо того чтобы сначала отправить транзакцию «разрешаю», а потом транзакцию «выполни», можно подписать сообщение один раз и передать подпись сразу вместе с действием.
Подпись работает так: контракт восстанавливает из неё адрес — и это должен быть именно адрес владельца токенов. Только тогда разрешение считается легитимным.
Контракт Lixir 0xEFd1b12F5E3c35D7daE0D1449674C247566f9b76 допустил критическую ошибку: он проверял, что подпись восстанавливает какой-то ненулевой адрес — но не проверял, что этот адрес совпадает с адресом реального владельца токенов. Это всё равно что охранник проверяет, что у вас есть хоть какой-нибудь пропуск — но не смотрит, ваша ли на нём фотография.
Воспользовавшись этим, злоумышленник смог выставить разрешения на vault-токены от имени множества чужих адресов. Получив разрешения, он использовал чужие vault-токены для выхода из позиций — то есть предъявил чужие «квитанции» и забрал базовые активы.
В результате с Lixir были выведены: ~4 477 USDC, ~3 609 USDT, 2,58 ETH и ~24 182 токена LIX.
Ocean Protocol: манипуляция внутренним балансом пула
Сеть: Polygon
Транзакция: 0x6dc8a7fba1303faef3ec7afa770b90b17ec5ecd73b51229277a9b0492e285796
Что произошло
Пулы BPool в Ocean Protocol хранят два числа: фактический баланс токенов (реальное количество токенов на контракте) и внутренний резерв (то, что пул «считает» своим балансом для расчёта обменных курсов). В норме эти числа совпадают. Есть специальная функция gulp, которая принудительно синхронизирует их: берёт фактический баланс и записывает его как внутренний резерв.
Злоумышленник использовал эту функцию как инструмент манипуляции. Схема выглядела так:
1️⃣ Войти в пул — внести токены mOCEAN (версия токена OCEAN на Polygon).
2️⃣ Изменить фактический баланс токенов на контракте.
3️⃣ Вызвать gulp — заставить пул принять изменённый баланс как официальный внутренний резерв.
4️⃣ Выйти из пула — получить активы по выгодному расчёту, основанному на уже искажённых данных.
Повторяя эту последовательность (LOG_JOIN → Gulped → LOG_EXIT) несколько раз, злоумышленник каждый раз получал чуть больше, чем вносил.
Почему это стало возможным
Функция gulp по задумке — служебный инструмент для синхронизации данных. Но она не проверяет, кто и зачем её вызывает, и не защищена от вызова в середине цепочки операций. Это позволило злоумышленнику намеренно создать расхождение между реальным и «официальным» балансом, а затем принудительно его «исправить» в нужный момент — когда это давало максимальную выгоду при выходе из пула.
Движение средств
Оба инцидента связаны одним адресом злоумышленника: 0x3Fa8cF7FeA68C8E76A9838d77889464DdFb6a6cf
Lixir Finance (Ethereum): все полученные токены были обменяны на ETH и отправлены в миксер Tornado Cash.
Ocean Protocol (Polygon): токены OCEAN были переброшены в сеть Ethereum на тот же адрес злоумышленника, обменяны на ETH и также отправлены в Tornado Cash.
На момент расследования средства выведены через миксер, дальнейшее отслеживание существенно затруднено.
Заключение
Этот двойной инцидент примечателен тем, что один злоумышленник в один день воспользовался двумя совершенно разными уязвимостями в двух разных сетях. Ни одна из них не требовала особой технической сложности — обе были следствием недостаточно строгой проверки входящих данных.
В Lixir контракт верил любой подписи, не убеждаясь, что она принадлежит владельцу. В Ocean функция синхронизации баланса была доступна всем и в любой момент — что и позволило использовать её как рычаг для манипуляции.
Суммарный ущерб относительно невелик — около $24 тыс. Но оба случая наглядно показывают: даже небольшая небрежность в проверках может открыть дверь для атаки.
Команда «КоинКит» продолжает мониторинг адресов злоумышленника.
