Ретроспектива BlockSec по безопасности DeFi-протоколов в 2023 году

Несмотря на то, что бо́льшая часть 2023 года прошла для DeFi-протоколов в условиях «медвежьего» рынка, экосистема продолжает страдать от серьезных взломов из-за уязвимостей в протоколах. В частности, значительным стал ущерб в размере почти 200 миллионов долларов во время взлома Euler Finance. Тем временем появились новые тенденции в инцидентах безопасности DeFi, такие как уязвимости, вызванные компиляторами и несовместимостью между широко используемыми стандартами. Чтобы противостоять этим угрозам, сообщество предложило множество решений, включая мониторинг и аналитику угроз (threat intelligence). Хотя некоторые из этих мер доказали свою эффективность, мы считаем, что эти усилия носят эпизодический характер. Сообществу по-прежнему не хватает систематического подхода и руководств, которые помогли бы защитить DeFi-протоколы.

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

0x0. Новые тенденции в безопасности DeFi-протоколов

Тенденция I: Атаки на авторитетные протоколы

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

Помимо вышеперечисленных, Aave V2 был экстренно приостановлен после получения отчета об уязвимости от сообщества в ноябре. Хотя протокол не подвергся атаке, это всё равно вызвало опасения по поводу безопасности авторитетных протоколов.

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

К счастью, потери пострадавших были компенсированы в рамках планов, реализованных соответствующими протоколами. Например, Kyber Network объявила о намерении компенсировать средства пострадавшим пользователям через казначейство KyberSwap. Аналогичным образом, сообщество Curve проголосовало за предложение возместить поставщикам ликвидности финансовые потери. Эти меры являются шагами к восстановлению доверия DeFi-сообщества, пусть и при значительных затратах.

Тенденция II: Появление новых типов векторов атак

В DeFi-пространстве действительно появились векторы атак, связанные с ошибками компиляторов и несовместимыми сторонними библиотеками. Например, основной причиной инцидента с безопасностью Curve были признаны ошибки в определенных версиях компиляторов Vyper. Кроме того, некоторые протоколы подверглись атакам, возникшим из-за несовместимости между двумя широко распространенными стандартами: ERC2771 и Multicall при их реализации в популярных сторонних библиотеках разработки, таких как thirdweb. Эти сложные технические проблемы подчеркивают важность тщательных практик безопасности и постоянного совершенствования мер защиты от новых и непредвиденных уязвимостей.

Ошибки компилятора

В 1983 году Кен Томпсон выступил с лекцией при получении премии Тьюринга под названием «Размышления о доверии к доверенному» (Reflections on Trusting Trust). В ней он описал шаги по модификации компилятора C для внедрения бэкдора в программу, что может привести к неожиданным результатам. Идея, высказанная в лекции, получила широкое признание в сообществе. Однако реальные случаи использования вредоносных компиляторов на практике встречаются редко (за исключением известных инцидентов безопасности XcodeGhost). Даже если ослабить модель безопасности с «вредоносных компиляторов» до доброкачественного, но неожиданного поведения компилятора, публичные случаи, повлекшие значительные финансовые потери, всё ещё остаются редкостью.

Инцидент безопасности Curve, вызванный ошибкой компилятора Vyper, — один из публично известных случаев, приведший к потерям примерно в 70 миллионов долларов (часть средств была возвращена, реальные потери составили около 23 миллионов). Версии компилятора Vyper 0.2.15, 0.2.16 и 0.3.0 содержат ошибки, которые делают защиту от повторного входа (reentrancy guard) неэффективной. Это означает, что злоумышленник может использовать reentrancy для совершения взлома, чего не должно происходить, если компилятор генерирует правильный байт-код — поскольку разработчик уже добавил код для предотвращения подобных ситуаций.

Tx атаки: 0x2e7dc8b2fb7e25fd00ed9565dcc0ad4546363171d5e00f196d48103983ae477c

Несовместимость общих стандартов

Композитность (сочетаемость) DeFi позволяет разным смарт-контрактам и стандартам взаимодействовать между собой для создания мощных приложений. Однако это создает потенциальные проблемы совместимости. Например, объединение популярных стандартов может привнести новые уязвимости безопасности, даже если каждый смарт-контракт по отдельности функционирует безупречно.

Одним из примеров такой проблемы несовместимости является взаимодействие стандартов ERC-2771 и Multicall. ERC-2771 определяет интерфейс для получения мета-транзакций через доверенный ретранслятор (forwarder), а Multicall — это механизм для пакетной обработки нескольких вызовов функций в рамках одной транзакции. Проблема возникает, когда вызов, перенаправленный с доверенного ретранслятора, извлекает адрес фактического вызова из calldata, который может быть изменен злоумышленником. Хотя каждый стандарт работает безупречно в изоляции, их совместное использование может нарушить определенные допущения и привести к непредвиденным проблемам. Более подробную информацию читайте в блоге OpenZeppelin.

Обратите внимание, что оба стандарта, ERC-2771 и Multicall, реализованы в популярных библиотеках разработки, таких как OpenZeppelin и thirdweb. Разработчики часто доверяют этим известным кодовым базам и могут исключать их из аудита кода. Такая практика может привести к появлению новых дыр в безопасности, даже если сами протоколы изначально не были уязвимы.

Тенденция III: Старые уязвимости имеют новые последствия для безопасности

Потеря точности (precision loss) означает снижение точности вычислений, обычно возникающее, когда результат имеет меньше знаков после запятой, чем ожидалось. Хотя статические анализаторы легко обнаруживают проблемы потери точности, само их наличие не обязательно указывает на уязвимость. Это считается уязвимостью только в том случае, если потеря точности может привести к серьезным последствиям. Однако оценка влияния потери точности часто сложна, так как требует глубокого понимания семантики протокола и конкретного контекста кода.

Несколько атак были направлены на протоколы, являющиеся форками других ведущих протоколов, таких как Compound v2 и Aave v2, которые могут быть подвержены известным проблемам точности. В частности, инциденты, связанные с Hundred Finance и Channels Finance — форками Compound v2, — были вызваны неправильной инициализацией рынков, а также проблемами потери точности. Эти ошибки позволяли злоумышленникам выкупать обеспечение, получая меньшее количество токенов из-за ошибок округления вниз.

Tx атаки: 0x3f7de75566289224c5e95a35ee8717ddd6928500227a05c1d83838844c60491d

0x1. Текущие решения

Действительно, авторитетные DeFi-протоколы вложили значительные средства в меры безопасности и прошли несколько раундов аудитов безопасности. Тем не менее, учитывая огромные объемы пользовательских активов, управляемых этими протоколами, критически важное значение безопасности протоколов неоспоримо. Помимо аудита кода, существуют и другие предлагаемые решения, такие как мониторинг угроз. Давайте разберем текущее состояние этих решений и их ограничения.

Аудит кода

Аудит кода, в том виде, в котором он здесь определен, является важнейшим процессом оценки безопасности DeFi-протоколов, который обычно проводится до запуска протокола. Он включает в себя ряд методов, включая ручной обзор кода, статический анализ, динамическое фаззинг-тестирование и формальную верификацию. Кроме того, этот процесс может проводиться одной (или несколькими) аудиторскими компаниями либо с помощью метода сообщества. Однако необходимо признать ограничения аудита кода.

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

• Во-вторых, аудит кода часто не может выявить тонкие уязвимости, требующие сложных взаимодействий и специфических состояний системы для эксплуатации. Композитность DeFi-протоколов, будучи функцией, способствующей гибкости и интеграции, значительно расширяет пространство состояний программы и создает серьезные проблемы для рецензентов и статических анализаторов, которым трудно исследовать весь диапазон состояний программы. Хотя динамическое фаззинг-тестирование может быть полезным, оно ограничено зависимостями от транзакций и состояний. Отсутствие оракулов для фаззинга, понимающих DeFi-протоколы и способных обнаруживать сбои, является серьезным пробелом в этой области, который остается открытым вопросом для исследований как в индустрии, так и в научных кругах.

• В-третьих, наблюдается нехватка квалифицированных аудиторов кода, что не может быть быстро решено из-за ограниченности кадрового резерва. Аудит кода — это междисциплинарная задача, требующая знаний в области кибербезопасности, финансов и математики. Лишь небольшое количество университетов в настоящее время предлагает обучение в этой специализированной области, что ведет к высокой стоимости качественного аудита и длительному ожиданию услуг. В результате протоколы могут запуститься без аудита, чтобы уложиться в сроки бизнес-плана.

• В-четвертых, пользователям сложно оценить качество проведенного аудита кода. Хотя пользователи больше всего заинтересованы в безопасности протокола, поскольку они доверяют ему свои активы, большинству из них не хватает навыков для оценки тщательности аудита. Это может приводить к тому, что аудит проводится лишь «для галочки», что в конечном итоге может скомпрометировать безопасность как самого протокола, так и активов пользователей.

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

Мониторинг угроз

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

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

• Во-вторых, текущее состояние систем мониторинга угроз часто требует ручного подтверждения для принятия мер после выявления подозрительных транзакций. Это во многом связано с вышеупомянутой проблемой высокой частоты ложных срабатываний. Реактивная природа ручного вмешательства является проблематичной, так как в быстро меняющейся среде блокчейна и DeFi-протоколов атаки могут истощить ресурсы очень быстро, зачастую до того, как удастся предпринять меры вручную. Таким образом, ценность системы мониторинга значительно снижается, если она не может обеспечить своевременные автоматические действия для предотвращения или смягчения последствий атак.

• Кроме того, мониторинг угроз должен быть постоянным и способным адаптироваться к новым угрозам по мере их появления.

0x2. Взгляд BlockSec

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

• Во-первых, мы считаем необходимым тщательное тестирование безопасности для любого, даже небольшого обновления кода или конфигурации. Такие тесты должны проводиться на реальных состояниях протокола, а не на фиктивных данных пользователей. Как обсуждалось ранее, состояния протокола имеют решающее значение для обнаружения уязвимостей в сложных системах.

• Во-вторых, необходима автоматическая система реагирования на атаки, помимо ручного вмешательства. Это требует точной и быстрой системы обнаружения атак с крайне низким уровнем ложноположительных и практически нулевым уровнем ложноотрицательных результатов. Например, активы миллионов пользователей могут быть спасены при развертывании автоматической системы реагирования.

• В-третьих, должны быть установлены надлежащие процедуры реагирования на инциденты безопасности, а также найдены партнеры по безопасности, способные предоставлять комплексные услуги. Например, при возникновении взлома партнер может помочь в создании «военного штаба» для реагирования, рекомендовать действия, помочь в проверке и аудите патчей безопасности, отслеживать потоки средств и т.д. Статья от yearn finance — отличный ресурс о том, как справляться со взломами.

Полнофункциональный сервис безопасности от BlockSec

Опираясь на полученные знания, BlockSec предоставляет протоколам полный спектр услуг безопасности.

• Качественный аудит кода. BlockSec предоставляет услуги по тщательному аудиту кода для DeFi-протоколов. Используя инструменты статического анализа, динамического фаззинга и инфраструктуру дифференциального тестирования, опирающуюся на передовые академические исследования, наши аудиты охватывают как сами протоколы, так и лежащий в их основе движок выполнения EVM. Кроме того, инструмент статического анализа HookScan получил поддержку со стороны Uniswap Lab для обнаружения уязвимостей в хуках Uniswap V4.

• Phalcon: Система обнаружения и блокировки атак. Благодаря методам, доказавшим свою эффективность при предотвращении более 20 атак и спасении активов на сумму около 14 миллионов долларов США, BlockSec Phalcon помогает протоколам активно отслеживать контракты и транзакции атак (даже до того, как хакер отправит транзакцию атаки). Благодаря движку для обнаружения атак с точностью почти 99,99% и настраиваемым политиками, BlockSec Phalcon балансирует между ложноположительными и ложноотрицательными срабатываниями, обеспечивая механизм автоматической защиты.

• Реагирование на инциденты. BlockSec — это всегда самый быстрый (если не первый) провайдер услуг безопасности, который способен определить первопричины атак и уязвимости в DeFi-взломах. Мы помогаем протоколам проверять патчи безопасности (Telcoin), предоставляем услуги по спасению средств [например, AnySwap, TransitSwap, Paraspace, Loot], отслеживаем движение украденных средств и устанавливаем личность хакера Hopeland.

0x3. Заключение

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

В заключение, целостный подход BlockSec к безопасности DeFi-протоколов, объединяющий передовые методы аудита, инструменты автоматической защиты от атак и оперативное управление инцидентами, делает нас ведущим партнером для проектов, стремящихся укрепить свои меры безопасности и защитить активы пользователей перед лицом новых угроз в DeFi-пространстве в 2024 году.