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