TL;DR
- Безопасность остается критической и постоянной проблемой в DeFi: ежегодно теряются миллиарды долларов.
- Меры безопасности для DeFi-протокола должны охватывать весь его жизненный цикл, обеспечивая защиту как внутренних, так и операционных аспектов с момента до запуска и после него. Крайне важно внедрять превентивные стратегии и планы действий на случай непредвиденных обстоятельств для смягчения потенциальных атак.
- Безопасность до запуска, сосредоточенная на аудите кода, стала консенсусом в сообществе. Однако, несмотря на появление решений по безопасности после запуска (например, мониторинг и блокировка атак), их важность еще не была полностью осознана сообществом.
- Постоянное совершенствование практик безопасности и переход к культуре «безопасность прежде всего» необходимы для защиты активов пользователей и повышения доверия к экосистеме.
Введение
Поскольку DeFi продолжает менять финансовый ландшафт, безопасность остается серьезной проблемой в рамках экосистемы, где ежегодно происходят потери на миллиарды долларов.
Согласно данным Chainalysis, взломы DeFi-протоколов в 2023 году привели к убыткам на сумму более 1,1 миллиарда долларов. Хотя эта цифра снизилась по сравнению с 2022 годом, в 2023 году появились новые тенденции во взломах DeFi. Например, были взломаны авторитетные протоколы, такие как Curve и KyberSwap, которые годами работали безопасно. Кроме того, были обнаружены изощренные атаки на уязвимости инфраструктуры, например, ретранслятор Flashbots.
В первой половине 2024 года произошло более пятидесяти взломов, повлекших за собой убытки, превышающие 100 тысяч долларов, согласно данным панели инцидентов безопасности.
Безопасность является важнейшим фактором для процветания и массового внедрения DeFi-приложений. Это связано с тем, что DeFi-протоколы управляют активами пользователей на миллиарды долларов, и любые взломы, направленные на эти протоколы, могут привести к значительным потерям для пострадавших пользователей. Хотя в некоторых случаях украденные средства могут быть (частично) возвращены (как в случае с инцидентом безопасности Euler), мы не можем рассчитывать на это каждый раз. Каждая атака подрывает доверие людей к DeFi.
Несмотря на то, что было предложено множество методов повышения безопасности DeFi, потенциал для улучшений все еще огромен.
- С положительной стороны, аудит кода стал общепринятым стандартом безопасности в сообществе. Большинство протоколов проходят аудит кода перед запуском, что помогает уменьшить площадь атаки, вызванную уязвимостями в смарт-контрактах.
- Однако одного лишь аудита кода далеко не достаточно для решения всех проблем безопасности. Он не может предотвратить взломы, возникающие из-за уязвимостей, появившихся при обновлении смарт-контрактов, изменении конфигурации и зависимостей времени выполнения в различных протоколах.
Из-за этих ограничений появились и были приняты некоторыми протоколами более активные решения, такие как операционный мониторинг или системы обнаружения атак.
В этом блоге мы изучим ландшафт безопасности DeFi, проследив путь безопасности протокола на различных этапах: от фазы перед запуском, через операционный этап и до реагирования на атаку. Мы подробно остановимся на различных типах мер безопасности и выделим основных вендоров (продукты) на каждом этапе, обсуждая их плюсы и минусы. Мы надеемся, что наши выводы помогут сообществу лучше понять современное состояние дел и, что более важно, вдохновят на создание инновационных решений в будущем.
Ландшафт безопасности DeFi
Меры безопасности для DeFi-протокола должны охватывать весь его жизненный цикл — от этапа перед запуском до этапа после запуска — обеспечивая как внутреннюю, так и операционную безопасность протокола. Кроме того, крайне важно иметь превентивные меры и планы действий на случай непредвиденных обстоятельств для борьбы с потенциальными атаками. Чтобы помочь читателям разобраться в доступных решениях, мы классифицируем вендоров (продукты) безопасности DeFi по следующим категориям.
Безопасность перед запуском
Эта категория включает в себя меры безопасности, которые проводятся перед запуском протокола, включая аудит кода, формальную верификацию и тестирование безопасности.
Услуги по аудиту кода и конкурсы
Аудит кода — это признанная практика безопасности в сообществе для защиты протокола. В этом процессе код проверяется охранными компаниями полуавтоматическим способом: автоматически сканируется на наличие распространенных уязвимостей и вручную анализируется на наличие сложных проблем. К числу ведущих компаний относятся OpenZeppelin, ChainSecurity, BlockSec и другие.
Кроме того, существуют платформы для проведения аудиторских конкурсов, которые отличаются от компаний тем, как проводится аудит. Эти платформы инициируют конкурс, привлекают исследователей безопасности из сообщества для проведения аудита и распределяют вознаграждение тем, кто нашел проблемы в протоколе. Конечно, платформы могут иметь некоторые тонкие различия в способах оценки серьезности, алгоритме распределения наград и критериях привлечения исследователей. Такие платформы включают Code4rena, SHERLOCK, Cantina и Secure3.
Аудит кода (и конкурсы) — это основная линия обороны безопасности протокола. Однако у него есть практические ограничения, что объясняет, почему многие протоколы, прошедшие аудит у авторитетных компаний, все равно подвергаются взломам.
- Во-первых, статический аудит кода не может полностью оценить проблемы безопасности, вызванные зависимостями протокола, особенно из-за компонуемости DeFi-протоколов.
- Во-вторых, влияние некоторых проблем на безопасность недооценивалось во время аудита. Например, потеря точности — распространенная проблема, которую могут упустить как аудиторы, так и команды протоколов. Ее влияние на безопасность не было полностью признано сообществом до инцидентов Hundred Finance и Channels Finance.
- Наконец, высококачественный аудит кода остается престижным и дефицитным ресурсом, требующим междисциплинарных талантов, владеющих знаниями в области безопасности, финансов и информатики. В настоящее время лишь немногие университеты могут постоянно подготавливать таких специалистов в больших масштабах. Таким образом, протоколы могут проходить аудит у компаний, не обладающих достаточной квалификацией.
Формальная верификация
«Формальная верификация — это процесс доказательства или опровержения корректности системы по отношению к определенной формальной спецификации или свойству с использованием формальных математических методов». Поскольку она позволяет доказать корректность систем, формальная верификация применяется к DeFi-протоколам. В частности, она может гарантировать, что поведение протокола соответствует формальной спецификации. Представителем продуктов для формальной верификации DeFi-протоколов является Prover, разработанный Certora. Разработчики предоставляют правила (спецификацию), а Prover сравнивает результаты с этими правилами, изучая все возможные состояния программы для поиска ошибок.
Наиболее перспективным аспектом формальной верификации является то, что она математически доказывает корректность DeFi-протокола. Однако на практике остаются ограничения, препятствующие ее широкому внедрению.
- Во-первых, спецификация должна быть предоставлена разработчиками, что требует наличия хорошо задокументированного описания ожидаемого поведения протокола. Это непросто, учитывая, что многие разработчики не являются экспертами в этой области.
- Во-вторых, частые обновления протокола могут потребовать обновления спецификаций и повторной оценки. Некоторые протоколы могут не позволить себе такие затраты времени и усилий.
Тем не менее, формальная верификация должна проводиться протоколами, особенно новыми, которые еще не прошли проверку временем, но управляют значительными активами пользователей. Однако повышение удобства использования и увеличение темпов внедрения формальной верификации остаются постоянной проблемой.
Тестирование безопасности
Тестирование безопасности относится к процессу использования тестовых сценариев (test cases) для поиска ошибок в протоколе. По сравнению с формальной верификацией, которая математически доказывает корректность протокола, тестирование безопасности обычно использует конкретные входные данные вместо символических, поэтому оно гораздо эффективнее, но менее надежно.
- Foundry — один из популярных фреймворков для разработки и тестирования смарт-контрактов. Разработчики могут запускать тесты во Foundry. Он также предоставляет возможности для выполнения фаззинг-тестирования, инвариантного и дифференциального тестирования DeFi-протоколов.
- Другие инструменты тестирования безопасности включают Tenderly и Hardhat.
Безопасность после запуска
Эта категория включает меры безопасности, которые проводятся после того, как протокол был запущен (или работает в основной сети), в том числе программы Bug Bounty, обнаружение атак и операционный мониторинг.
Bug Bounty (Программы вознаграждения за ошибки)
Программы Bug Bounty создают мост между протоколами и исследователями безопасности. Основная концепция заключается в стимулировании исследователей сообщать об уязвимостях нулевого дня в обмен на вознаграждение. В частности, протоколы могут размещать свои программы на платформах Bug Bounty, детализируя область охвата и размер вознаграждения. Immunefi — одна из представительных платформ Bug Bounty в Web3.
Обнаружение атак
Платформы обнаружения атак сканируют транзакции, чтобы найти вредоносные. В частности, эти платформы проверяют транзакции, взаимодействующие с протоколом, на наличие вредоносного поведения. Если такая транзакция происходит, срабатывает оповещение.
- Например, BlockSec Phalcon сканирует транзакции и использует механизм обнаружения на основе поведения для выявления вредоносных действий (таких как вредоносные контракты или предложения). Представьте это как виртуального охранника, который наблюдает за каждым шагом финансовой операции в поисках подозрительного поведения. Он извлекает поведенческие паттерны из транзакций, как детектив анализирует улики, а затем использует финансовые модели — подобные тем, что применяют банки для выявления мошенничества — для определения потенциальных атак.
- Похожие системы включают продукты, предоставляемые Hypernative и Hexagate.
- Кроме того, Venn Security network от Ironblocks предоставляет децентрализованную инфраструктуру для объединения результатов обнаружения из различных источников.
Операционный мониторинг
Фреймворки операционного мониторинга предоставляют способ реализации операционной безопасности для DeFi-протоколов. Например, протоколу необходимо знать об изменении ключа администратора, выполнять развертывание и обновление смарт-контрактов, а также автоматически сканировать пул-реквесты на наличие уязвимостей.
- OpenZeppelin Defender предоставляет платформу, которая позволяет разработчикам безопасно писать, развертывать и эксплуатировать смарт-контракты.
- BlockSec Phalcon может отслеживать риски, связанные с обновлениями контрактов, созданием транзакций кошелька Safe, новыми подписями и выполнением, контролем доступа и управлением (governance).
- Forta Network обладает инфраструктурой, позволяющей пользователям создавать собственные боты для мониторинга своих протоколов или подписываться на существующие боты для получения оповещений о фишинге или угрозах.
Реагирование на атаку
Эта категория включает меры, принимаемые, когда атака уже произошла, включая блокировку атак, автоматические действия, создание «военных комнат» (war room), анализ первопричин и отслеживание потока средств атакующего.
Среди пяти мер по реагированию на атаки, блокировка атак особенно примечательна, поскольку позволяет командам проектов внедрять превентивные меры заранее, успешно блокируя атаки до их исполнения и сводя потери к нулю. Платформы автоматического реагирования также помогают уменьшить ущерб, причиненный атаками.
Создание «военной комнаты», проведение анализа первопричин и отслеживание украденных средств — это реактивные шаги, предпринимаемые после того, как атака уже произошла. Хотя эти стратегии могут смягчить часть ущерба и помочь предотвратить подобные атаки в будущем, потери уже могут быть значительными, и их может быть трудно возместить. Кроме того, репутации проекта и доверию пользователей может быть нанесен глубокий удар.
Риски повсюду и часто выходят из-под контроля, однако решение развернуть превентивные меры защиты вполне доступно и настоятельно рекомендуется.
Блокировка атак
Обнаружения атак на практике недостаточно для борьбы со взломами. Это связано с тем, что без возможности автоматической блокировки ручные ответы недостаточно быстры. В некоторых случаях (KyberSwap, Gamma Strategies и Telcoin в таблице ниже) протоколу требуется несколько минут или даже часов для принятия действий вручную, что слишком поздно для спасения активов. При недавних взломах Velocore и Rho была приостановлена работа целых сетей Linea и Scroll, что вызывает опасения по поводу централизации L2-сетей.
Блокировка атак — это возможность автоматически предотвращать взломы, требующая двух ключевых техник: раннего обнаружения и автоматического фронтраннинга (опережения) атак.
- Раннее обнаружение означает, что система может идентифицировать транзакции атаки до их завершения в блокчейне, в частности, пока они все еще находятся в мемпуле.
- Опережение атаки предполагает отправку транзакции в цепочку раньше транзакции атакующего с целью приостановки протокола, что эффективно останавливает атаку до ее исполнения.
В этой категории BlockSec Phalcon — единственный продукт, обладающий этими ключевыми возможностями. После того как хакер инициирует транзакцию атаки, механизм мониторинга Phalcon может немедленно обнаружить ее, отправить оповещения пользователям и автоматически приостановить протокол, сводя потери к нулю. Эти ключевые техники были проверены в реальных условиях при более чем двадцати спасениях активов на сумму свыше 20 миллионов долларов США.
Автоматическое действие
Платформы, такие как Phalcon, Hexagate и Hypernative, также могут реагировать автоматически при возникновении атаки.
Подписавшись на такие платформы, пользователи могут настроить мониторинг и меры реагирования на различные риски протокола. Если транзакция соответствует правилам мониторинга, система автоматически инициирует заданные пользователем действия (например, приостановку протокола), тем самым уменьшая потери.
Однако некоторые платформы не имеют механизма обнаружения атак, и система не может напрямую распознать вредоносную транзакцию и уведомить пользователя. Вместо этого они требуют от пользователей настройки условий, при которых транзакция может считаться атакой. Поскольку характеристики атак очень сложны, а пользователи (часто разработчики контрактов) могут не обладать достаточными знаниями в области безопасности, это может оказаться довольно сложной задачей для них.
Военная комната (War Room)
Создание «военной комнаты» необходимо, когда протокол находится под атакой. Это помогает протоколу понять ситуацию, обменяться информацией в сообществе и привлечь ресурсы для дальнейших действий. Обычно это требует участия экспертов с различными компетенциями.
SEAL 911 — это проект, призванный «предоставить пользователям, разработчикам и исследователям безопасности доступный способ связи с небольшой группой высокопрофессиональных специалистов по безопасности в экстренных случаях». Связаться с ними можно через Telegram-бота SEAL 911. В случае взлома проекта может быть создана «военная комната» для оказания помощи протоколу.
Анализ первопричин
Когда происходит атака, протокол должен понять первопричину, например, наличие уязвимости в смарт-контрактах и то, как она была использована. Для этого нужны полезные инструменты анализа транзакций атаки. Для этой цели можно использовать Phalcon Explorer, OpenChain и Tenderly.
Отслеживание потока средств
Отслеживание потока средств необходимо для мониторинга начальных средств атакующего и его прибыли в блокчейне с целью определения связанных адресов и сущностей. Если активы поступают в централизованные организации (например, централизованные биржи и другие учреждения), можно связаться с правоохранительными органами для содействия в заморозке средств.
В этой категории работает ряд компаний и инструментов, включая Chainalysis, TRM Labs, ARKHAM, ELLIPTIC, MetaSleuth и другие.
- Например, MetaSleuth, разработанный BlockSec, может автоматически отслеживать средства в разных цепочках, используя богатую маркировку адресов кошельков.
- ARKHAM имеет сообщество, где протокол может назначить награду за расследование, что стимулирует сообщество помогать в отслеживании средств атакующего.
Образовательные ресурсы по безопасности
Информированность создает более надежную защиту. Помимо упомянутых выше вендоров и продуктов безопасности, существует еще один важнейший компонент безопасности DeFi: образовательные платформы.
Эти платформы предоставляют важные ресурсы для практиков и пользователей DeFi, помогая понять аспекты безопасности, повысить осведомленность и развить навыки защиты. Они играют жизненно важную роль в развитии безопасности DeFi. Мы выражаем признательность этим образовательным платформам и перечисляем несколько заслуживающих внимания примеров.
- SΞCURΞUM: Discord-сообщество, сосредоточенное на безопасности Ethereum. Также проводит ежемесячную викторину по безопасности смарт-контрактов «Secureum RACE».
- Панель инцидентов безопасности: Эта платформа собирает все инциденты атак с ущербом более 100 000 долларов, детализируя потери, затронутые цепочки, уязвимости, первопричины и доказательства концепции (PoC).
- Rekt: Известный как даркнет DeFi-журналистики, Rekt предоставляет глубокий анализ эксплойтов, взломов и мошенничеств в экосистеме.
- RugDoc: Сообщество по безопасности и обучению в DeFi, которое оценивает риски проектов. Также включает платформу RugDocWiKi, знакомящую с экосистемой и технологиями DeFi.
- DeFiHackLabs: Web3-сообщество по безопасности с более чем 2600 участниками и почти 200 белыми хакерами, целью которого является объединение экспертизы в области безопасности Web2 и Web3.
- Solodit: Платформа, которая компилирует исторические отчеты различных Web3-аудиторских компаний, служащая ценным ресурсом для аудиторов смарт-контрактов.
- Ethernaut: Web3/Solidity-игра, в которой игроки ищут уязвимости в контрактах Ethereum, аналогично CTF-задачам.
Заключение
Безопасность остается постоянной и серьезной угрозой для DeFi-экосистемы, вызывая потери на миллиарды долларов каждый год. В настоящее время большинство мер безопасности выполняется на этапе перед запуском. Однако «серебряной пули» в безопасности не существует, и различные методы должны применяться на протяжении всего жизненного цикла DeFi-протокола. Мы ожидаем, что индустрия будет внедрять решения по безопасности после запуска для мониторинга и, что более важно, для автоматической блокировки атак. Мы надеемся, что в экосистеме будет установлена культура «безопасность прежде всего» для полной защиты активов пользователей.
