Рынок Децентрализованных финансов успешно продолжает завоевывать доверие инвесторов. Тем не менее, вопросы безопасности DeFi, связанные с растущим количеством последних атак на протоколы, вызывают массу споров по поводу надежности и безопасности технологии децентрализованного финансирования. В этой статье, вы узнаете, как максимально обезопасить свои DeFi проекты и причины последних взломов широко известных dApps протоколов, к чему они привели.
Сумма залоченных средств в DeFi растет в геометрической прогрессии и недавно превысил $15 миллиардов, по данным DeFiPulse. Очевидно, что быстроразвивающийся рынок привлекает огромное внимание и со стороны хакеров, стремящихся попытать удачу и заработать легких денег. И к сожалению, сейчас наблюдается немало примеров атак на протоколы, которые происходят по большей части из-за пренебрежения безопасностью со стороны владельцев DeFi проектов. Рассмотрим несколько примечательных взломов с начала 2020 года.
Атака на dForce.
Ошибки в кодах проектов играют важную роль в генерации дополнительных лазеек для ушлых хакеров, при помощи которых они имеют возможность выкачивать деньги из пулов ликвидности. Часто эти уязвимости возникают из-за желания проекта как можно быстрее выйти на рынок, чтобы извлечь выгоду из растущего спроса, не проходя хотя бы начальный надлежащий аудит безопасности. Хорошим примером данного фактора стал взлом dForce 20 апреля, в результате которого дефект в стандарте токенов ERC-777 позволил совершить атаку, так называемую, “Reentrancy attack”.
По ссылке есть информация о данном типе атак: https://consensys.github.io/smart-contract-best-practices/known_attacks/
Одна из резонансных атак была предпринята по протоколу dForce и привела к потере $25 миллионов. Проект пострадал от вторичной атаки на смарт-контракт с использованием токена стандарта ERC-777.
dForce используют децентрализованный протокол lendf.me, разработанный фондом самого проекта для обеспечения возможности кредитования в сети блокчейна Ethereum. Как известно, стандарт токенов ERC-777 был изначально нацелен на расширение возможностей ERC-20 и не имеет уязвимостей. Однако, комбинация контрактов ERC-777 и Lendf.me позволяет осуществить подобную атаку с целью получить средства инвесторов.
Токен ERC-777 имеет возможность информировать отправителя или получателя о переводе токенов. Если же получатель является смарт контрактом (в данном случае из протокола Lendf.me), то в нем можно выбрать, как "отвечать" на определенный отправленный токен. Одной из таких ответных реакций может быть повторное обращение к договору о передаче токена и последующая отправка. Данная функция позволяет осуществить атаку и вывести из протокола все средства.
Что интересно, в конечном итоге все средства были возвращены после того, как хакер случайно слил собственный IP-адрес.
Стоит заметить, что модель dForce контрактов имеет примерно такую же структуру, как и контракты Compound, поэтому копирование исходных кодов других протоколов навряд ли станет гарантированной защитой от возможных взломов.
Атака на Harvest Finance.
Атака на Harvest произошла несколько недель назад и являлась одним из последних случаев. В отличие от dForce, Harvest пострадал "благодаря" уязвимости в смарт-контракте, что конкретно проявилось в недостатке модерации функций арбитража.
Хакер выявил уязвимость в функционале арбитража и с использованием опции флэш-кредитования смог получить $50 миллионов на Uniswap v2. Для осуществления атаки он манипулировал ценами стейблкоинов через протокол Curve.fi.
$10 млн USDT были переведены в USDC через пул ликвидности на платформе Curve для снижения стоимости USDT, затем следующие $40 млн USDT были обменяны на fUSDT в Harvest Finance. Затем $10 млн. USDC были обменяны обратно на USDT на Curve для повышения цены USDT, что, в свою очередь, заставило курс USDT по отношению к fUSDT также повыситься. Затем хакер просто поменял fUSDT обратно на USDT и получил среднюю прибыль в $500,000. Повторив это несколько раз, он смог сгенерировать $24 миллиона до того, как его “спалили”.
В результате этой атаки, хакер вывел больше средств, чем депонировал, и таким образом опустошил пул, что в совокупности привело к потере Harvest 24 миллионов долларов в стейблкоинах.
Последний случай схож с двумя атаками, которые произошли на bZx в течение той же недели в феврале этого года. Опять же, это было результатом непроверенной арбитражной возможности, которая позволила хакерам заработать порядка 1 миллиона долларов в ETH - и никто ничего не мог с этим поделать.
Это классические примеры того, что понимается под ошибкой бизнес-логики, когда в инфраструктуре платформы создается благоприятная для использования возможность для хакеров, в основном это связано с отсутствием у разработчиков необходимых финансовых знаний, чтобы предвидеть подобные лазейки.
Как защитить DeFi протокол от атак хакеров?
Как правило, взломы происходят из-за одной из трех постоянных проблем. Ошибки бизнес-логики, ошибки кодирования и проблемы, возникающие во внутренних механизмах управления. Далее мы разберемся, как можно максимально обезопасить dApps протоколы от взломов. Это не гарантирует 100% защиту, но это основные моменты, которые нужно учитывать при разработке того или иного децентрализованного продукта.
1. ПОЛНОЕ МОДУЛЬНОЕ ТЕСТИРОВАНИЕ.
Юнит-тесты являются неотъемлемой частью любого качественного тестирования проекта. Это позволяет выявить проблемы функциональности в отдельных частях контрактов и устранить их в самом начале. Важно то, что контракты требуют полного покрытия юнит-тестами, а не только 60% или 70% покрытия самых важных частей кода.
2. АУДИТ БЕЗОПАСНОСТИ СМАРТ-КОНТРАКТОВ.
И все же, если выполнены все тесты по всем методам, классам и модулям, это все равно не дает гарантии, что контракт будет идеально функционировать. Полное покрытие юнит-тестами не определяет все возможные пути и комбинации, по которым попадает пользователь, поэтому аудит безопасности следует рассматривать как следующий шаг. Это помогает обнаружить неравномерные и неожиданные уязвимости smart-контрактов до развертывания проекта и, следовательно, помогает предотвратить возможный взлом DeFi.
3. ВТОРИЧНЫЙ АУДИТ.
Одного аудита перед развертыванием проекта недостаточно и взлом протокола dForce является прекрасным тому примером. Хотя стандарт токена ERC-777 считается менее уязвимым, это не означает, что его интеграция с Lendf.me станет идеально гладкой. То же самое касается и при внедрении с imBTC. Если бы они проверили все возможные функции, они могли бы избежать такого неудачного опыта.
4. УНИКАЛЬНОСТЬ КОДА.
Остановившись на примере dForce, можно с уверенностью сказать, что откровенный копипаст кода с других протоколов - не самая лучшая идея. Просто, если разработчики не форкают весь проект, то они пытаются разбавить отдельные части кода, которые часто будут несовместимы с тем, что уже есть. Это будет основной причиной возможно будущих эксплойтов.
5. БИЗНЕС ЛОГИКА.
Ошибки бизнес-логики можно легко исправить, протестировав должным образом протокол DeFi в тестируемой или бета-фазе перед запуском, и убедившись, что функция проверки арбитража имеет более низкое значение допуска, чем 2%.
6. ДЕПОЗИТЫ.
Функции депозита также должны быть не доступны для сторонних смарт-контрактов, или, по крайней мере, должны определяться определенные лимиты значений, если они есть.
Наконец, что касается плохого управления со стороны основателей DeFi протоколов. Вообще, лучший способ для трейдеров (и пользователей) оградить себя от попадания в руки мошенников - это проявить строгую предусмотрительность перед тем, как расстаться с криптой. Проверка технического описания проекта, команды, деятельности сообщества, биржевых листингов, количества аудитов безопасности, а также поддержка институциональных инвесторов даст вам куда более четкое представление о том, стоит ли совершать инвестиции в тот или иной проект децентрализованных финансов или нет.
