Back to Blog

№8: Инцидент с SushiSwap: неуклюжая попытка спасения привела к серии атак подражателей

Code Auditing
February 18, 2024
5 min read

9 апреля 2023 года SushiSwap стал целью эксплойта из-за не прошедшего проверку внешнего параметра. Общий ущерб составил около 3,3 миллиона долларов.

Поскольку такие ведущие протоколы на Ethereum обладают обширной пользовательской базой, они все равно остаются уязвимыми к возникновению серьезных новых проблем при обновлении контрактов. Это напоминание для DeFi-сообщества о том, что безопасность всегда должна быть главным приоритетом. Более того, данный инцидент безопасности был спровоцирован попыткой «белого хакера» спасти средства, что вызвало значительные споры в сообществе. Мы представляем краткий обзор этого инцидента, отмечая его как один из десяти главных инцидентов безопасности 2023 года.

История вопроса

SushiSwap

SushiSwap, известная децентрализованная биржа (DEX), запустила «вампирскую атаку» на Uniswap, добившись колоссального успеха. На пике ее TVL достигал 8 миллиардов долларов, и сейчас он все еще составляет около 400 миллионов долларов.

Одобрение (Approval)

Если кратко: это разрешение контракту получать доступ к определенному токену в вашем кошельке и переводить его.

Для удобства многие контракты по умолчанию запрашивают неограниченное одобрение. Многие пользователи, опасаясь рисков безопасности, вносят лишь небольшие суммы в различные протоколы. Однако эти пользователи предоставляют протоколам одобрение на использование безлимитных средств. Если протокол будет скомпрометирован, все одобренные токены на счете могут быть потеряны.

Уязвимость

Непроверенный внешний параметр

Функция processRoute() контракта RouteProcessor2 позволяет пользователям полностью контролировать поток вызовов (параметр route). А в uniswapV3SwapCallback() параметр from функции safeTransferFrom() декодируется из предоставленного пользователем route. В результате пользователи, давшие одобрение контракту RouteProcessor2, потеряли свои активы.

Процесс атаки

Этот инцидент включал множество транзакций атаки, но мы используем первую из них в качестве примера. Транзакция: 0x43ff7e01423044cfb501b4fe9ef1386725c0ddc117dadd6e6620cb68bdeaf4f9

  1. Злоумышленник вызвал processRoute() уязвимого контракта RouteProcessor2 с тщательно сконструированным длинным аргументом route.
  2. processRouteInternal() создает InputStream на основе маршрута, предоставленного пользователем.
  3. Транзакция следовала по route атакующего до вызова swapUniV3(). Обратите внимание, что pool декодируется из stream, что означает, что злоумышленник контролировал, в каком именно pool будет выполняться swap(), установив его как lastCalledPool.
  4. Это вызвало вредоносный контракт, развернутый атакующим, который затем просто передал вредоносные calldata для обратного вызова uniswapV3SwapCallback() контракта RouteProcessor2.
  5. uniswapV3SwapCallback() требует проверки msg.sender, но поскольку lastCalledPool уже был установлен на вредоносный контракт, хакер обошел эту проверку. Важно отметить, что параметр from функции safeTransferFrom() был декодирован из сконструированных атакующим calldata.
  6. Активы жертвы переводятся на вредоносный контракт, развернутый атакующим.

Спорное спасение «белым хакером»

Стоит отметить, что «белый хакер» с никнеймом @trust__90 выявил эту проблему и предпринял попытку спасти средства, но эта попытка обернулась катастрофой.

  • Он использовал мемпул для трансляции транзакций вместо приватного RPC.
  • Он попытался спасти только 100 Ether вместо всех средств, находящихся под угрозой.

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

Спасение силами BlockSec

В ходе этой атаки мы также спасли 100 Ether и вернули средства жертве, 0xsifu.

На сегодняшний день мы успешно предотвратили более 20 реальных хакерских атак и спасли активов на сумму более 14 000 000 долларов.

Рекомендации по безопасности

Обновления всегда должны проходить аудит

Это напоминание DeFi-сообществу о том, что безопасность всегда должна быть главным приоритетом. Аудиты не являются гарантией безопасности, но отсутствие аудита точно не гарантирует безопасность.

Смягчение проблем с одобрением (Approve)

В 2023 году произошло множество инцидентов, связанных с атаками через одобрения, и мы пользуемся этой возможностью, чтобы вновь подчеркнуть важность управления разрешениями. Практика безопасности заключается в том, чтобы одобрять использование только необходимых сумм, или, если приоритетом является удобство, одобрять лишь немного большую сумму, чем требуется.

Инструмент MetaSuites от BlockSec предлагает удобную функцию диагностики одобрений. Кроме того, для регулярной проверки статусов одобрения можно использовать такие сервисы, как Revoke Cash.

Внедрение механизмов мониторинга и автоматического реагирования

Ethereum — это «темный лес», и каждый в DeFi-сообществе сталкивается с различными рисками и проблемами, даже эксперты по безопасности. В 2023 году мы запустили Phalcon Security — первую в отрасли систему автоматического реагирования, предназначенную не только для мониторинга атак, но и для активной блокировки угроз в режиме реального времени. Проверенные в бою возможности Phalcon доказали свою эффективность, успешно предотвратив более 20 реальных атак и сохранив активы стоимостью более 14 000 000 долларов. Эта инновация гарантирует, что все участники рынка могут спать спокойнее, зная, что для защиты их инвестиций приняты проактивные меры.

Читайте другие статьи из этой серии:

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit