~$1,35 млн потеряно: BarnBridge, DeFiTuna | Еженедельник BlockSec

За прошедшую неделю (2026/07/13 - 2026/07/19) зафиксированы следующие 2 notable инцидента безопасности с совокупными потерями около $1,35 млн в сетях Ethereum и Solana.

• DeFiTuna: Проверка здоровья позиции принимала нулевое значение актива как здоровое при ненулевом долге; злоумышленник использовал контролируемую маршрутизацию свопов и отдельный пул с низкой ликвидностью, чтобы активировать этот дефект и создать позицию с безнадёжным долгом.
• BarnBridge: Устаревшая система управления была использована для изменения критической конфигурации протокола и вывода одобренных пользователями средств.

Главное за неделю: DeFiTuna

Первопричиной стала некорректная ветка обработки нулевого значения в проверке здоровья позиции: позиция с нулевой стоимостью активов и непогашенным долгом ~$570K была принята как здоровая. Злоумышленник активировал этот дефект, направив своп через отдельный пул с низкой ликвидностью, однако именно проверка здоровья должна была предотвратить возникновение безнадёжного долга.

16 июля 2026 года DeFiTuna, протокол кредитования на Solana с поддержкой плечевых спотовых позиций, был атакован приблизительно на $570K в USDC [1]. Первопричиной стала некорректная ветка обработки нулевого значения в проверке здоровья позиции, которая принимала позицию как здоровую даже при нулевой стоимости активов и ненулевом долге. Злоумышленник открыл плечевую позицию с нулевым залогом, занял USDC из хранилища протокола и направил своп через подконтрольный ему пул с низкой ликвидностью, в результате чего позиция получила ничтожное количество целевого токена. Усечение точности округлило стоимость позиции до нуля, и проверка здоровья приняла позицию как здоровую, создав безнадёжный долг приблизительно на $570K.

Предыстория

DeFiTuna — протокол кредитования на Solana с поддержкой маржинальной торговли. Пользователь может открыть спотовую позицию, предоставив один токен в качестве залога, заняв средства из хранилища протокола и обменяв заёмные средства на целевой токен. Полученная позиция затем проверяется на соответствие долгу для определения её здоровья.

На спотовом рынке DeFiTuna два токена пула обозначаются как токен A и токен B. На атакованном рынке токеном A был TUNA, а токеном B — USDC.

• USDC был токеном залога (collateral_token). Пользователь вносит USDC в качестве маржи, занимает дополнительный USDC из хранилища DeFiTuna, после чего заёмный USDC обменивается на TUNA.
• TUNA был токеном позиции (position_token) — активом, который позиция удерживает после свопа. Итоговый эффект — плечевая длинная позиция по TUNA, финансируемая долгом в USDC.
• Счета хранилища содержат ликвидность кредиторов и являются источником заёмных средств.
• Пул AMM обеспечивает рыночную ликвидность и ценовой контекст для пары TUNA/USDC.

DeFiTuna маршрутизирует свопы позиций через Jupiter — агрегатор свопов на Solana. Путь свопа передаётся в инструкцию DeFiTuna в виде данных маршрута Jupiter и аккаунтов маршрута. Поскольку эти аккаунты предоставляет вызывающая сторона, она контролирует, через какой пул выполняется своп. Перед выполнением свопа DeFiTuna проводит проверку цены, сравнивая цену обычного рыночного пула с ценой оракула.

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

Уязвимая программа — DeFiTuna (tuna4u...nogD).

Первопричиной стала некорректная ветка обработки нулевого значения в проверке здоровья позиции. После свопа DeFiTuna оценивал позицию, переводя удерживаемый TUNA в единицах USDC. Если баланс TUNA был достаточно мал для округления до нуля, поле total принимало значение 0. Логика проверки здоровья трактовала total == 0 как здоровое состояние, не требуя при этом debt == 0.

Анализ атаки

Два свойства дизайна дали злоумышленнику контроль над маршрутизацией заёмных средств. Во-первых, DeFiTuna принимал предоставленные вызывающей стороной данные Jupiter RouteV2, не вычисляя самостоятельно минимально допустимый вывод TUNA на основе цены оракула и суммы займа. Во-вторых, проверка оракула перед свопом валидировала только обычный рыночный пул DeFiTuna, а не тот пул, который фактически использовал маршрут Jupiter.

Примечание: Анализ инцидента, одобренный командой проекта [1], описывает созданный злоумышленником пул как инициализированный вблизи легитимной цены оракула. Данные в блокчейне свидетельствуют о том, что пул был инициализирован по экстремальной цене; проверка перед свопом была пройдена, поскольку она валидировала отдельный обычный рыночный пул, а не пул под контролем злоумышленника.

Следующий анализ основан на транзакции 4x33Dq...EXj1. Было выполнено несколько атакующих транзакций; данная иллюстрирует основную технику.

• Шаг 1: Злоумышленник создал новый пул Fusion TUNA/USDC. Этот пул использовал настоящие минты TUNA и USDC, но был отдельным от обычного рыночного пула DeFiTuna. Пул был инициализирован по экстремальной цене вблизи тика 208636, оценивая TUNA примерно в 1,149 миллиарда USDC за TUNA. При такой цене даже ничтожное количество TUNA могло поглотить сотни тысяч USDC в ходе свопа.

• Шаг 2: Злоумышленник разместил два небольших лимитных ордера на продажу в новом пуле. Каждый ордер внёс 0.000526 TUNA, итого 0.001052 TUNA. Поскольку цена пула была крайне высокой, это ничтожное предложение TUNA могло поглотить всю сумму заёмного USDC при выполнении свопа.

• Шаг 3: Подготовив пул, злоумышленник открыл спотовую позицию DeFiTuna с TUNA в качестве токена позиции и USDC в качестве токена залога. Злоумышленник предоставил 0 USDC в качестве залога и занял 570,000 USDC из хранилища USDC DeFiTuna.

• Шаг 4: Перед свопом DeFiTuna сравнил цену обычного рыночного пула с ценой оракула. Спотовая цена обычного пула была близка к цене оракула, поэтому проверка была пройдена. Данная проверка валидировала только обычный рыночный пул DeFiTuna; пул Fusion не проверялся.

• Шаг 5: Своп следовал предоставленному злоумышленником маршруту Jupiter, который направлял средства через подконтрольный злоумышленнику пул Fusion с минимальным выводом, фактически установленным на ноль. После уплаты комиссии протокола 569,601 USDC был направлен в атакующий пул, тогда как позиция DeFiTuna получила лишь 494 сырых единицы TUNA (0.000494 TUNA).

• Шаг 6: После свопа позиция удерживала долг приблизительно в 570,000 USDC и лишь пылевое количество TUNA. Когда DeFiTuna конвертировал баланс TUNA в стоимость в USDC, результат округлился до 0. Проверка здоровья трактовала total == 0 как здоровое состояние, поэтому позиция с безнадёжным долгом была принята.

• Шаг 7: Злоумышленник вывел USDC, накопленный в подконтрольном ему пуле Fusion. Два вывода были почти равными, соответствуя двум позициям лимитных ордеров, созданным на шаге 2.

Заключение

Первопричиной стала ветка total == 0 в проверке здоровья, принимавшая позицию как здоровую вне зависимости от наличия непогашенного долга. Маршрутизация и ликвидность под контролем злоумышленника создали условия для активации этого дефекта, однако именно проверка здоровья являлась финальным контролем, который должен был предотвратить возникновение безнадёжного долга.

Наиболее прямым исправлением является отклонение любой позиции, где total == 0 и debt > 0. Позиция с нулевой стоимостью и непогашенным долгом никогда не является здоровой. Кроме того, протокол должен самостоятельно вычислять минимально допустимый вывод свопа на основе цены оракула и суммы займа, независимо от предоставленных вызывающей стороной параметров маршрута. Привязка проверки оракула/цены к фактическому пулу свопа или верификация вывода свопа относительно вычисленного протоколом минимума предотвратила бы обход проверки перед свопом путём маршрутизации через невалидированный пул.

Ссылки

• [1] Заявление DeFiTuna об инциденте

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

BarnBridge

15 июля 2026 года BarnBridge, протокол распределения доходности на Ethereum, был атакован приблизительно на $776K в USDC [1]. Первопричиной стало то, что заброшенный контракт управления сохранил полномочия на изменение критической конфигурации протокола. Злоумышленник приобрёл достаточную долю голосов для принятия вредоносного предложения, заменившего контроллер компонента протокола, после чего использовал новый контроллер для перевода одобренного пользователями USDC.

Предыстория

BarnBridge — протокол под управлением DAO, распределяющий средства пользователей по различным рынкам кредитования для получения дохода. Голосовая сила определяется количеством застейканного BOND и сроком блокировки. Для создания предложения требуется голосовая сила не менее 1% от общей. Предложение должно набрать минимальный кворум в 40% и получить не менее 60% голосов участников «за», чтобы быть принятым. После подачи предложение проходит двухдневный период подготовки, трёхдневный период голосования и двухдневный период очереди, прежде чем может быть исполнено.

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

Первопричиной стало то, что заброшенный контракт управления сохранил полномочия на изменение критической конфигурации протокола после его вывода из эксплуатации. Система управления контролировала назначение Controller для CompoundProvider — контракта, которому пользователи ранее одобрили расходование своего USDC. Поскольку BarnBridge был выведен из эксплуатации, общий объём застейканного BOND и активное участие значительно снизились, что сделало прохождение враждебного предложения тривиально достижимым.

Анализ атаки

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

Злоумышленник потратил приблизительно 0,335 ETH на приобретение около 32 795 BOND, затем внёс и заблокировал 32 000 BOND, получив примерно 43% от общей голосовой силы.

• Шаг 1: Злоумышленник развернул прокси-контракт и подал вредоносное предложение. После двухдневного периода подготовки злоумышленник использовал всю свою голосовую силу «за», выполнив требования как по кворуму, так и по одобрению.

• Шаг 2: Злоумышленник поставил предложение в очередь. После истечения двухдневного периода очереди злоумышленник исполнил его, установив Controller для CompoundProvider в значение прокси-контракта злоумышленника.

• Шаг 3: Злоумышленник обновил логику прокси-контракта и вызвал _takeUnderlying(), который использовал непогашенные разрешения на USDC примерно 50 пользователей для перевода их USDC в CompoundProvider. Затем злоумышленник вызвал transferFees() для перенаправления средств на адрес злоумышленника, получив прибыль приблизительно $776K в USDC.

Заключение

При выводе DAO или протокола из эксплуатации его контракт управления должен отказаться от полномочий или навсегда заблокировать возможность изменения критически важных для безопасности конфигураций — особенно прав администратора, контроллера и вывода средств. Конкретные меры включают отзыв роли администратора контракта управления над нижестоящими контрактами, передачу владения на адрес сожжения или исполнение финального предложения, отключающего функции обновления и устанавливающего ссылки на контроллеры в неизменяемые безопасные значения. Сохранение полномочий управления в выведенном из эксплуатации протоколе создаёт низкозатратную поверхность атаки: по мере снижения участия капитал, необходимый для достижения кворума, пропорционально уменьшается.

Ссылки

• [1] Оповещение Phalcon: эксплойт BarnBridge

• Начните работу с Phalcon Security

  Обнаруживайте каждую угрозу, получайте важные оповещения и блокируйте атаки.

  Попробовать бесплатно