Web3. Безопасность. DeFi. Случаи взломов форков
Введение
С ростом популярности децентрализованных финансов (DeFi) многие разработчики форкали исходный код топовых ("тир-1 // 2") DeFi-протоколов – таких как Uniswap, Curve, Compound, MakerDAO – и запускали свои версии на новых блокчейнах или с дополнительными функциями.
Однако, отклонения от проверенного боем кода или недостаточное тестирование приводили к уязвимостям.
Ниже приведены основные случаи взломов форков известных DeFi-протоколов в 2017–2025 гг., не включая оригинальные тир-1 протоколы. Каждый случай содержит название проекта, год инцидента, форк какого протокола он представляет, краткое описание вектора атаки, оценку ущерба и рекомендации, как избежать подобных атак.
Краткий обзор случаев
Список составлен по следующему образцу:
- 2020
- примерно $25 млн
- Reentrancy-атака через ERC777-токен
Uranium Finance (fork Uniswap V2):
Venus Protocol (fork Compound):
- 2021
- $100 млн (долг)
- Манипуляция ценой токена XVS (оракул/коллатерал)
- В 2026-ом - снова взлом
Cream Finance (fork Compound):
Rari Fuse (Fei) (fork Compound):
Hundred Finance (fork Compound):
Теперь попробую рассмотреть эти случаи более подробно...
Lendf.Me (2020) – форк Compound (dForce)
Описание атаки
Проект Lendf.Me от dForce (Ethereum) был форком протокола Compound для лендинга и заимствований. В апреле 2020 года хакер воспользовался уязвимостью повторного входа (reentrancy): платформа добавила поддержку нестандартного токена imBTC на базе ERC-777, который позволяет вызывать обратные вызовы при переводах токенов.
Злоумышленник сначала внёс imBTC в залог, а затем в ходе обратного вызова повторно вывел первоначальный депозит до обновления баланса, создав иллюзию дополнительного залога. Это позволило многократно увеличить "баланс" залога и затем вывести почти все средства из пулов Lendf.Me.
Ущерб
За несколько транзакций было похищено около $25 млн в различных криптоактивах. (Примечательно, что спустя некоторое время хакер вернул большую часть средств под давлением сообщества и правоохранителей, но сам факт взлома выявил серьёзную уязвимость).
Рекомендации по защите
Данный инцидент показал опасность интеграции новых токен-стандартов без должного аудита. Во избежание повторных атак такого типа следует обеспечивать защиту от reentrancy-атак при работе со сторонними токенами (например, использовать реентрантные блокировки и проверять совместимость нового стандарта с логикой протокола).
Кроме того, важно тщательно тестировать и аудировать смарт-контракты при добавлении новых типов залоговых токенов. Эксперты отмечали (и тоже - не зря), что "копипаст" кода без полного понимания его работы опасен – несовместимости при простом клонировании могут приводить к эксплойтам.
Uranium Finance (2021) – форк Uniswap V2 (BSC)
Описание атаки
Uranium Finance - автоматизированный маркет-мейкер (AMM) на Binance Smart Chain, форк Uniswap V2 (через код SushiSwap). В апреле 2021 года, во время миграции на версию 2.0, команда внесла мелкие изменения в код протокола, которые оказались фатальными.
В частности, разработчики заменили кое-где константу комиссии 1000 на 10000, но допустили ошибку в проверке инварианта x*y=k. Из-за этой опечатки проверка баланса токенов после свопа перестала корректно работать.
В результате атакующий смог за один минимальный обмен получить практически весь резерв второго токена из пула - то есть обменять ничтожное количество одного актива на десятки миллионов долларов другого. По сути, из-за неверного коэффициента в формуле протокол позволил обойти принцип сохранения произведения резервов.
Ущерб
В течение нескольких минут злоумышленник опустошил 26 пулов на общую сумму около $50–57 млн (в различных токенах: BNB, BUSD, ETH, BTCB, ADA и др.).
Этот взлом стал одним из крупнейших на BSC на тот момент. Команда Uranium успела осознать наличие бага и планировала обновление, однако атакующий опередил их, воспользовавшись уязвимостью в период между миграциями.
Рекомендации по защите
Данный случай наглядно продемонстрировал риск неосторожных изменений в проверенном коде. Основатель Uniswap Хейден Адамс заметил, что не было никакой разумной причины менять эти строчки кода.
Отсюда: рекомендуется максимально сохранять проверенную логику оригинального протокола при форке. Если изменения необходимы, они должны проходить полный аудит и тестирование.
В частности, для AMM критично соблюдать корректность проверки инварианта баланса (x*y=k): нельзя убирать или модифицировать эту логику без тщательного анализа.
Кроме того, стоило бы запустить баунти-программу или привлекать внешних аудиторов до миграции - в случае Uranium баг был выявлен, но обновление задержалось, что дало окно для атаки.
BurgerSwap (2021) - форк Uniswap V2 (BSC)
Описание атаки
BurgerSwap - ещё один форк Uniswap V2 на BSC. В мае 2021 года он подвергся flash loan-атаке с повторным входом и манипуляцией цены. Атакующий взял мгновенный займ (flash loan) в WBNB через PancakeSwap, после чего создал фейковый токен и торговую пару BURGER/фейк-токен на BurgerSwap.
Отсутствие полноценной проверки инварианта x*y=k в форке (кусок кода Uniswap был попросту опущен) позволило провернуть следующую схему: сначала злоумышленник ввёл в пул 100 фейковых токенов и 4500 BURGER, искусственно завысив цену BURGER, затем обменял эти 100 фальшивых токенов обратно на 4400 WBNB. Используя уязвимость повторного входа, он затем ещё раз обменял ок. 45 тысяч BURGER на 4400 WBNB по нереалистично завышенному курсу. В итоге через пару итераций атакующий вывел из протокола большое количество разных токенов, включая ок. 4 млн долларов в BURGER/xBURGER и другие альткоины.
Ущерб
Общий прямой ущерб пользователям составил примерно $7.2 млн (в эквиваленте). Цена токена BURGER резко упала из-за мгновенной продажи похищенных монет.
Причиной уязвимости стала отсутствующая критическая проверка формулы постоянного произведения (x*y=k) в коде форка: контракт позволял выкупать активы из пула по искаженной цене.
Рекомендации по защите
Flash loan-атаки с ценовыми манипуляциями стали типовой угрозой для DeFi. В случае BurgerSwap эксплойт стал возможен из-за расчета цены внутри смарт-контракта, уязвимого к манипуляции баланса. Рекомендуется использовать независимые ценовые оракулы или дополнительные проверки, чтобы курс обмена не основывался исключительно на локальном балансе токенов, который злоумышленник может временно изменить.
Например, привязка к рыночной цене из внешнего источника или введение ограничения на величину ценового воздействия за одну транзакцию могли бы предотвратить такую атаку. Также важно внедрять защиту от повторного входа (reentrancy guard) в чувствительных функциях обмена, чтобы злоумышленник не мог вызывать их рекурсивно до обновления состояния контракта.
Venus Protocol (2021) - форк Compound/Maker (BSC)
Описание атаки
Venus Protocol - крупнейший лендинговый протокол на BSC, форк Compound с элементами MakerDAO (алгоритмический стейблкоин VAI). В мае 2021 года Venus понёс огромные потери из-за манипуляции ценой собственного токена управления XVS.
Перед инцидентом параметры протокола были изменены: доля заёмных средств под залог XVS (Collateral Factor) увеличена с 60% до 80%. Это позволило заемщикам брать больше средств под залог XVS. Затем в течение нескольких часов некий крупный игрок начал агрессивно скупать XVS, взвинтив цену с ~$80 до ~$145. На пике цены XVS этот участник внёс огромный депозит XVS в Venus и занял против него максимальные объёмы BTC и ETH. Как только токены были выведены, XVS стремительно обрушили обратно до $80, вызвав массовую ликвидацию залогов.
Ущерб. Поскольку цена XVS вернулась к исходной, проданный залог не покрыл выданные займы, и на балансе протокола образовался невозмещённый долг свыше $100 млн.
В ходе этой "волатильности" было ликвидировано позиций более чем на $200 млн (часть средств ушла ликвидаторам и самому манипулятору), а непокрытый убыток Venus составил примерно $100 млн "плохих" долгов.
Данная атака не эксплуатировала баг в коде – вместо этого был использован экономический уязвимый момент: зависимость протокола от рыночной цены токена XVS и слишком высокий допустимый процент заимствования под него.
Рекомендации по защите
- Чтобы избежать подобных ситуаций, протоколам важно ограничивать риски залога, особенно если залогом служит собственный мало ликвидный токен. После инцидента Venus предложил снизить Collateral Factor для XVS обратно и использовать казначейские резервы для покрытия убытков пользователей.
- Использовать надёжные оракулы цен (например, Chainlink) для токенов, подверженных манипуляции;
- Вводить лимиты на максимальные займы под высоковолатильный залог; и
- Применять механизмы паузы протокола при экстремальных ценовых колебаниях.
Также инцидент показал опасность стремительного повышения лимитов без надлежащего стресс-тестирования - изменения параметров протокола управления должны проходить через анализ рисков.
Cream Finance (2021) - форк Compound (Multi-chain)
Описание атаки
Cream Finance – мультичейн-протокол кредитования, один из известных форков Compound. К несчастью, 2021 год стал для него чередой взломов. Крупнейший инцидент произошёл 27 октября 2021 года: атакующий провёл сложную многоэтапную атаку, задействовав flash-loan и уязвимости в ценообразовании залоговых токенов.
В частности, Cream поддерживал в качестве залога токен Yearn yUSD - долю в доходном агрегаторе. Смарт-контракт Cream рассчитывал стоимость yUSD через так называемый гибридный оракул, зависящий от pricePerShare внутри самого Yearn-вуалта.
Атакующий взял в долг огромные суммы (через flash mint DAI и flash loan ETH), внёс их в Yearn-пулы, получил yUSD и несколько раз депонировал один и тот же залог через разные аккаунты, тем самым многократно увеличив "виртуальный" баланс своего обеспечения.
Затем он искусственно завысил цену yUSD, внеся ок. $10 млн в базовый пул Yearn непосредственно (что увеличило pricePerShare токена). Благодаря завышенной оценке залога и тройному учёту одного и того же депозита, злоумышленник смог сразу вывести весь доступный остаток ликвидности Cream (ETH, токены) под псевдо-залог и скрыться, погасив флэш-займы.
Ущерб
Атака опустошила эфирный пул Cream, ущерб оценён примерно в $130 млн. Это был третий взлом Cream за год (до этого были эксплойты на $37 млн и $19 млн), после которого доверие к проекту было подорвано.
Рекомендации по защите
Случай Cream Finance показал уязвимость Compound-подобных протоколов к сложным атакам на систему залогов и оракулов. Рекомендуется ограничивать использование сложных производных активов в качестве залога - например, токенов доходных фермерств, которые сами имеют внутреннюю стоимость.
Если такие активы принимаются, оракул для них должен быть устойчив к манипуляциям (в идеале базироваться на надёжных внешних источниках цены, а не внутренних переменных контракта).
Также необходимы лимиты на депозиты и заимствования: протокол должен предотвращать ситуацию, когда один адрес может чрезмерно повысить свою позицию залога через цепочку транзакций.
В целом, все форки Compound должны регулярно обновлять безопасность в соответствии с найденными уязвимостями оригинала. После инцидента эксперты предупредили, что похожая reentrancy-уязвимость (как в Rari Fuse) может присутствовать и в других форках Compound, призвав команды провести аудит и исправления.
EasyFi (2021) - форк Compound (Polygon)
Описание атаки
EasyFi - кросс-чейн протокол кредитования (Polygon/BSC/Ethereum), основанный на коде Compound. В апреле 2021 года EasyFi не был взломан технически через смарт-контракт - вместо этого произошёл взлом административного ключа. Злоумышленнику удалось получить удалённый доступ к компьютеру основателя EasyFi (через малварь или фишинг) и завладеть приватным ключом администратора протокола.
Обладая админ-ключом, атакер перевёл себе 2.98 млн токенов EASY (управляющий токен платформы) с официального кошелька проекта. Затем эти токены были оперативно обменяны на стейблкоины (USDC) через Ethereum, что обвалило цену EASY (ок. $20 до взлома). Кроме того, используя ключ, хакер вывел ликвидность из пулов протокола на $6 млн (stablecoins, депозиты пользователей).
Ущерб
Суммарно проект оценивал потери примерно в $59–80 млн (разница возникает из-за волатильности EASY: около $6 млн напрямую из пулов + оставшаяся ценность 2.9 млн токенов EASY).
Токен EASY обесценился, и впоследствии команда выпустила новый токен EZ взамен, чтобы попытаться компенсировать инвесторам часть утраченной стоимости.
Рекомендации по защите
Этот инцидент подчеркнул критическую важность операционной безопасности (OpSec) для админ-ключей. Единоличное хранение приватных ключей на персональном компьютере недопустимо для DeFi-протокола, контролирующего крупные средства.
Рекомендуется использовать мультиподпись (multisig) для административных функций: распределение прав между несколькими доверенными лицами существенно усложняет задачу злоумышленнику.
Например, проект Lido распределил ключ между 11 участниками для повышения безопасности.
Если возможно, стоит стремиться к максимальной децентрализации управления – вплоть до отказа от админ-ключа ("сжечь ключ") после развёртывания протокола, как это сделал Tornado Cash.
По крайней мере, команды должны с первого дня придерживаться строгих правил OpSec: хранить ключи на отдельных устройствах, не подключенных к интернету, с резервными копиями в защищённых хранилищах, и регулярно проводить аудит процедур безопасности.
Rari Fuse / Fei Protocol (2022) - форк Compound (Ethereum)
Описание атаки
Rari Capital Fuse - модуль кастомных пулов кредитования, построенный на форке Compound, интегрированный в протокол Fei. 30 апреля 2022 года несколько Fuse-пулов были атакованы посредством уже известной уязвимости в исходном коде Compound.
Атакующий эксплуатировал ошибку повторного входа (reentrancy) в функции exitMarket() смарт-контракта, благодаря чему смог выкачать средства из пулов, вызывая запрещённые действия до обновления состояния контракта. Фактически, это была повторная атака типа, который ранее выявлялся в Compound: злоумышленник через вложенный вызов добился того, что протокол позволял забрать залог, не погасив полностью заем. В результате несколько Fuse-пулов Rari (включая пулы Fei) были опустошены.
Ущерб
Суммарные потери оцениваются примерно в $80 млн. Команда Fei приостановила заимствования во всех пулах и попыталась связаться с хакером, предлагая ему оставить $10 млн в качестве вознаграждения и вернуть остальное без вопросов.
Однако похищенные средства возвращены не были, и впоследствии сообщество Fei/Rari приняло решение закрыть Fuse-модули, столкнувшись с невозможностью покрыть ущерб.
Рекомендации по защите
Данный случай показал, что форки Compound унаследовали опасную уязвимость, если она не была своевременно исправлена. PeckShield публично предупредил все проекты, форкающие Compound, оперативно исправить баг в функции exitMarket и провести аудит безопасности своих пулов.
Рекомендуется регулярно синхронизировать форк с обновлениями исходного протокола, особенно если выявлены критические баги. Звучит банально? Да, но без этого нет никакого развития.
Кроме того, стоит внедрять модульные ограничения доступа - например, временные блокировки на повторный выход из рынков в рамках одной транзакции. Общий урок - даже проверенный код (Compound V2 считался безопасным) в контексте новых протоколов может дать сбой, поэтому необходимы bug bounty-программы и независимые аудиты, особенно при добавлении собственных модификаций.
Saddle Finance (2022) - форк Curve (Ethereum)
Описание атаки
Saddle Finance – AMM для стейблкоинов, во многом основанный на идеях Curve Finance. Вместо прямого форка кода Curve (написанного на Vyper) команда Saddle решила переписать логику Curve Meta-Pool на Solidity, чтобы настроить под свои нужды. К сожалению, при этой реализации были допущены ошибки.
В Curve Meta-Pool один из токенов представляет ликвидность из другого пула (LP-токен базового пула), поэтому при свопах нужно учитывать виртуальную цену LP-токена.
В коде Saddle эта корректировка не была учтена при обмене LP-токена на основной стейблкоин – формула рассчитывала количество выдаваемого стейблкоина без поправки на возросшую со временем виртуальную цену LP-токена.
В результате LP-токен оценивался чересчур дорого, и злоумышленник мог получить больше базового актива, чем должен. 30 апреля 2022 года атакующий через три последовательные транзакции (с флэш-займами) как раз воспользовался этим несоответствием в пуле sUSD – Saddle DAI/USDC/USDT Meta-Pool.
Он обменивал USDC на sUSD, затем sUSD на LP-токен пула, затем обратно на sUSD и в конечном счёте выводил больше USDC, чем внёс, повторяя цикл.
Ущерб
За утро 30 апреля было украдено около $10–11 млн в эквиваленте. Примечательно, что одна из трёх атакующих транзакций исходила от "белого хакера", который выявил уязвимость почти одновременно с черным хакером и сумел вывести ок. 25% средств в безопасное место, чтобы затем вернуть их проекту.
Остальные 75% (около $7.5 млн) потеряны для протокола.
Рекомендации по защите
Ошибка Saddle Finance возникла из-за отклонения от боевой проверенной реализации Curve. Урок здесь в том, что не стоит заново реализовывать сложные математические алгоритмы ценообразования, если можно использовать готовый и аудированный код.
Любые изменения (например, перевод с Vyper на Solidity) требуют крайне тщательной проверки. Команде Saddle следовало провести более глубокий аудит или формальную верификацию алгоритма расчёта цены в метапулах.
После инцидента они оперативно приостановили свопы и исправили функцию, добавив недостающий коэффициент виртуальной цены. Общая рекомендация для подобных протоколов: покрыть тестами все пограничные случаи расчётов (например, обмен токена пула на базовый токен) и учитывать исторические атаки на форки (ранее подобный баг эксплуатировался на сходных платформах Nerve и Synapse).
В целом, при форках математически сложных DeFi-протоколов предпочтительно либо не вносить изменений в формулы, либо привлекать нескольких независимых аудиторов для проверки корректности каждой формулы.
Hundred Finance (2023) - форк Compound (Multichain)
Описание атаки
Hundred Finance - форк Compound V2, развёрнутый на нескольких сетях (Ethereum, Optimism и др.). 16 апреля 2023 года его пул на Optimism подвергся специфической атаке, связанной с ошибкой округления и пустыми пулами.
В Compound-подобных протоколах для каждого актива существует производный токен (например, hUSDC для USDC), и курс обмена между ними (exchangeRate) определяется формулой, учитывающей баланс актива в контракте, суммарные займы, резервы и эмиссию hToken.
Если пул почти пустой (низкий totalSupplyhToken) и возникают дробные значения при вычислении, неточности округления могут резко завысить exchangeRate.
В случае Hundred атакующий воспользовался рынком с очень малой ликвидностью: внёс крохотный депозит, спровоцировав экстремальное значение exchangeRate, после чего смог вывести непропорционально большую сумму базового актива.
По сути, он манипулировал курсом обмена hToken через “пустой” пул, получив на вывод больше, чем изначально внёс (в комбинации с flash loan для увеличения эффекта).
Ущерб
Атака привела к потере примерно $7.4 млн с платформы Hundred Finance. Средства были выведены в токенах, после чего, вероятно, конвертированы и отмыты, т.к. возврата не произошло.
Этот инцидент привлёк внимание к целому классу уязвимостей, связанных с потерей точности чисел с плавающей запятой в DeFi-протоколах. Вслед за Hundred аналогичные атаки были зафиксированы на платформах Midas и Radiant (тоже форках Compound), использовавших схожие механизмы, что говорит о системности проблемы.
Рекомендации по защите
Для предотвращения подобных атак разработчикам форков Compound/Aave следует обращать внимание на обработку погрешностей при экстремальных значениях.
Рекомендуется вводить минимальные пределы ликвидности: например, требовать минимальный депозит в новый пул, или игнорировать расчёт exchangeRate, если в пуле нулевой или слишком малый баланс, чтобы избежать деления на почти ноль.
Полезно установить пределы изменения exchangeRate за одну транзакцию – это затруднит злоумышленнику скачкообразно изменить курс. Также необходимо улучшить тестирование: моделировать ситуации с пустыми или близкими к пустым пулами.
Данный случай подчёркивает, как мне кажется, что даже без явных багов точность вычислений имеет значение для безопасности. После атаки Hundred Finance были предприняты шаги к компенсации пользователей и патчу, а сообщество DeFi стало более внимательно относиться к "precision loss" эксплойтам. Каждый форк должен учитывать подобные инциденты и проактивно укреплять контракт против них.
Заключение
Рассмотренные случаи демонстрируют, что форки топ-протоколов DeFi уязвимы к разнообразным атакам – от тривиальных опечаток в коде до сложных экономических манипуляций и компрометации ключей.
Главные уроки (для меня опять же) включают:
- Необходимость тщательного аудита каждого изменения при форке,
- Использование надёжных ценовых оракулов,
- Внедрение лимитов и защит от флэш-кредитов и reentrancy,
- Строгую операционную безопасность админ-ключей.
DeFi-протоколы должны не только копировать успешные решения, но и уделять первоочередное внимание безопасности, учитывая опыт предыдущих взломов. Только так можно снизить риски повторения этих инцидентов в будущем и защитить средства пользователей.