Эксплойт, с которым Curve столкнулся на этот раз, может открыть новые идеи для хакеров

Джалил, BlockBeats

Индустрия DeFi погрузилась в хаос после инцидента с использованием уязвимости. Curve Finance, гигант индустрии DeFi, стал объектом серьезной «атаки», и несколько пулов стабильных монет, таких как alETH/msETH/pETH, находятся под угрозой. Согласно неполным статистическим данным, эксплойт уязвимости привел к общей потере 52 миллионов долларов США в пулах Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis и CRV/ETH, а доверие всего рынка было серьезно подорвано.

Блокировки повторного входа версий Vyper 0.2.15, 0.2.16 и 0.3.0 недействительны, а интерфейс установки официального документа Vyper рекомендует неправильную версию. Другие участники проекта, использующие компилятор Vyper, также поспешили провести самоанализ, пытаясь убедиться, что они не станут следующей жертвой. По мере того, как источник инцидента с использованием уязвимости постепенно раскрывается, рынок постепенно осознает, что этот кризис означает не только обычный инцидент с использованием хакерских программ, но и раскрывает потенциальный огромный риск всего базового стека для всей индустрии DeFi.

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

Хакеры, которые возвращаются к «первоначальным принципам», нашли идеальную точку входа в компилятор нижнего уровня, чтобы съесть огромный и вкусный «пирог» на рынке DeFi. Компилятор нижнего уровня стал более «умным» хакером». Выбор. Компания BlockBeats взяла интервью у разработчика смарт-контрактов Бокса (@BoxMrChen) и исследователя BTX Дерека (@begas_btxcap) об этом инциденте и связанных с ним проблемах.

Как происходит событие Curve?

Стани (@StaniKulechov), основатель Aave и Lens, выразил свое мнение об инциденте в социальных сетях: «Это досадная неудача для Curve и DeFi. Хотя DeFi — это открытое пространство, которое может внести свой вклад, оно должно быть абсолютно правильным. сложно, а ставки высоки. В случае с Curve они поняли это правильно на уровне протокола».

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

Реентерабельная блокировка и принцип CEI

Приведите простой пример, иллюстрирующий атаки с повторным входом: в банке всего 100 000 наличных денег. Но у этого банка есть большая лазейка: всякий раз, когда люди снимают деньги, сотрудники банка не обновляют баланс счета сразу, а ждут до конца дня, чтобы проверить и обновить. В это время кто-то обнаружил эту лазейку.Он открыл счет в банке, сначала положил 1000 юаней, затем снял 1000 юаней, а затем снял 1000 юаней через 5 минут. Поскольку банк не обновляет баланс в режиме реального времени, система будет думать, что на его счету еще есть 1000 юаней перед проверкой и обновлением. Путем повторных операций пользователь, наконец, вынул все наличные в банке в размере 100 000 долларов США. Только к концу дня банк обнаружил, что лазейка была использована.

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

Solidity устанавливает «принцип CEI» (Check Effects Interactions) для программирования смарт-контрактов, который может хорошо защитить функции от атак с повторным входом. Содержание принципов CEI включает:

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

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

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

4. Переменные состояния должны обновляться перед любыми внешними вызовами, чтобы предотвратить повторные атаки.

5. Даже доверенные внешние объекты должны следовать шаблону CEI, поскольку они могут передавать поток управления злонамеренным третьим сторонам.

Согласно документации, принципы CEI помогают ограничить поверхность атаки на контракт, в частности предотвращая повторные атаки. Принципы CEI могут быть легко применены, в основном в порядке функциональных кодов, без изменения какой-либо логики. Известный эксплойт The DAO, приведший к форку Ethereum, также игнорировал «принцип CEI», и злоумышленник добился повторной атаки, что привело к разрушительным последствиям.

Но атакованный пул Curve не следовал этому принципу CEI, потому что Curve использовал компилятор Vyper. Как уязвимость кода Vyper компилятора, блокировка повторного входа не работает, что делает хакерскую атаку повторного входа успешно реализованной.

Большинство людей знают Solidity, но Solidity — не единственный язык для создания смарт-контрактов, популярной альтернативой Solidity является Vyper. Хотя Vyper не так мощен и популярен, как Solidity, он идеально подходит для разработчиков, знакомых с Python, поскольку Vyper может переводить код, подобный Python, в язык программирования смарт-контрактов Ethereum.

Согласно информации github, разработчик, который первым вносит свой вклад в базу кода github Vyper, также является разработчиком Curve. Нетрудно объяснить, почему Curve использует Vyper вместо Solidity.

![Хакеры возвращаются к «первоначальным принципам», кризис Curve — это не обычная атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-c30cf03f91-dd1a6f-1c6801)

Почему блокировка повторного входа Vyper не работает?

Итак, в этой атаке в чем проблема с Vyper? Почему блокировка повторного входа не работает? Это потому что тестов нет? Компания BlockBeats взяла интервью у разработчика смарт-контрактов Box 826.eth (@BoxMrChen), по его словам, реентерабельная блокировка Vyper была протестирована с вариантами использования. Но причина провала в том, что тест-кейс ориентирован на результат, то есть тест-кейс тоже неправильный.

Короче говоря, самая большая причина, по которой блокировка повторного входа Vyper не работает, заключается в том, что человек, написавший тестовый пример, написал тестовый пример на основе результата, не задумываясь о том, почему слот необъяснимым образом пропускает 1.

![Хакеры возвращаются к «первоначальным принципам», кризис Curve — это не обычная атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-0527942e35-dd1a6f-1c6801)

В следующих абзацах кода Vyper, которым поделился Box, проблема хорошо видна. Когда имя блокировки появляется во второй раз, номер storage_slot будет перезаписан, то есть в ret слот для первого получения блокировки равен 0, но после того, как функция снова использует блокировку, слот для замка добавлен один. После компиляции используется неправильный слот, из-за чего повторная блокировка не вступает в силу.

![Хакеры возвращаются к «первоначальным принципам», кризис Curve — это не обычная атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-87ec9b545c-dd1a6f-1c6801)

Слева — атакованный код, справа — восстановленный код.

«Ожидаются неправильные результаты теста, и, конечно, никакие ошибки не могут быть проверены. Чтобы привести простой пример, мы сейчас решаем задачу расчета, 1 + 1 = 2, но данный стандартный ответ неверен, говоря, что 1 + 1 = 3 А это Одноклассник, который делал вопрос, дал неправильный ответ, и ответил 1+ 1 = 3, но это было то же самое, что стандартный ответ, данный заранее, поэтому программа, естественно, не имела возможности определить, что результат теста был неправильно», — сказал Бокс в интервью BlockBeats.

Два года висит "Дамоклов меч"

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

Чтобы получить более глубокое представление о редакторе Vyper, BlockBeats взял интервью у исследователя BTX Дерека (@begas_btxcap), он сказал, что для разработчиков, знакомых с Python, Vyper является более идеальным выбором, чем Solidity, с более удобным интерфейсом пользовательского интерфейса. и более быстрое обучение. Но, по-видимому, некоторые версии кода редактора Vyper не были проверены надежной третьей стороной. Даже некоторые аудиторские работы могут выполняться самими разработчиками. «В традиционной ИТ-индустрии такого не произойдет, потому что после появления нового языка бесчисленное множество аудиторских компаний будут искать ваши лазейки».

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

Участник Vyper fubuloubu также сказал: «Компилятор не подвергается такой проверке или аудиту, как все думают. Большинство компиляторов вносят существенные и частые изменения, что делает аудит невыгодным. Даже при полном аудите кодовой базы она устареет, если после этого будет добавлено больше версий. Аудит компилятора — плохая идея, потому что имеет смысл проверять конечный продукт (т. е. необработанный код EVM), созданный конечным пользователем с помощью инструмента.

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

Хакеры возвращаются к «первым принципам»

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

После этого Стани (@StaniKulechov), основатель Aave и Lens, также опубликовал в социальных сетях длинную статью, чтобы выразить свои чувства: Атака на Curve означает, что риск DeFi всегда связан со всем базовым стеком, языком программирования, EVM. , и т. д. Это предупреждает нас о необходимости быть более осторожными и чувствительными, особенно при использовании пользовательских EVM и цепочек приложений в будущем.

![Хакеры возвращаются к «первоначальным принципам», кризис Curve — это не обычная атака] (https://img-cdn.gateio.im/resized-social/moments-40baef27dd-3324fcfbcd-dd1a6f-1c6801)

Атаки с более низкого уровня

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

«В настоящее время лучшими являются только два компилятора, кодовая база Vyper меньше, ее легче читать и в ней меньше изменений для анализа ее истории, вероятно, поэтому хакеры начинают здесь, кодовая база Solidity немного больше», — fubuloubu даже подозревает, что государство- К этой атаке Curve могут быть причастны поддерживаемые хакеры: «Чтобы найти уязвимость, потребуются недели или месяцы, и, учитывая вложенные ресурсы, это может быть выполнено небольшой группой или командой».

Безопасность Solidity, как наиболее широко используемого языка компиляции в индустрии шифрования, еще больше беспокоит пользователей.В конце концов, если на этот раз у компилятора Solidity возникнет проблема сбоя блокировки повторного входа, то история всей индустрии DeFi может измениться. быть переписанным.

Согласно предупреждениям системы безопасности, регулярно выпускаемым командой разработчиков Solidity, во многих различных версиях компилятора Solidity обнаружены уязвимости.

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

Мы также можем увидеть файл в репозитории Solidity на Github, в котором перечислены некоторые известные ошибки, связанные с безопасностью, в компиляторе Solidity. Список восходит к версии 0.3.0, баги, существовавшие только до этой версии, не перечислены. Здесь есть еще один файл bugs_by_version.json. Этот файл можно использовать для запроса ошибок конкретной версии компилятора.

К счастью, именно из-за широкого применения языка Solidity и помощи Ethereum Foundation многие существующие проблемы были отмечены проектами и протоколами в процессе развертывания. Таким образом, Solidity выполнил модификацию и улучшение на несколько шагов быстрее, чем Vyper, и с этой точки зрения это одна из причин, почему Solidity более стандартизирована и безопаснее.

Чтобы помочь разработчикам Solidity лучше тестировать и предотвратить повторение подобных ошибок. Соучредитель UnitasProtocol SunSec (@ 1 nf 0 s 3 cpt) выпустил руководство по тестированию безопасности DeFiVulnLabs Solidity после атаки Curve, поддерживающее 47 типов уязвимостей, включая описания уязвимостей, сценарии, средства защиты, коды уязвимостей, меры по смягчению и способы тестирования. .

Как максимально избежать низкоуровневых атак?

В этом инциденте с Curve Бокс считает, что просвещение для всех разработчиков заключается в следующем: не пытаться следовать технологическому тренду и выбирать незрелые решения, не утверждать собственный код без написания тестовых случаев (несколько версий Vyper, у которых есть проблемы, даже тестовые случаи неверны); никогда не одобряйте свой собственный код; некоторые состояния могут открываться годами; отсутствие возможности обновления — это высокомерие по отношению к себе и презрение к другим.

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

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

Кроме того, модульные тестовые примеры для завершения кода. Большинство ошибок на уровне компилятора приведут к несогласованным результатам выполнения кода, которые трудно обнаружить только при проверке кода, но которые можно выявить при тестировании. Улучшение покрытия кода может помочь избежать таких проблем. И старайтесь избегать использования сложных функций языка, таких как встроенный ассемблер и кодирование и декодирование многомерных массивов, если в этом нет явной необходимости. Большинство уязвимостей языка Solidity исторически были связаны с этими расширенными функциями. Разработчикам следует избегать использования экспериментальных функций языка ради демонстрации без особой необходимости.

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

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