Автор: китайский блог Artela, Medium# Аннотация

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

«Защита во время выполнения» является важным дополнением к безопасности DeFi. Она направлена на «защиту результатов выполнения» и обеспечение того, чтобы выполнение протокола соответствовало его ожидаемому дизайну.

Конструкция EVM не поддерживает «защиту во время выполнения», поскольку смарт-контракт не может получить доступ к полной контекстной информации о состоянии во время выполнения.

Artela исследует парадигму уровня выполнения EVM+Extension, совершенствует уровень выполнения для устранения повторных атак

Artela реализует ончейн-расширения «защиты во время выполнения» с помощью аспектного программирования.

Мы пошагово показываем, как предотвратить реентерабельные атаки на контракт Curve через Aspect.

Почему атаки с повторным входом все еще остаются проблемой, несмотря на существующие средства контроля рисков

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

Финансовая атака Curve (июль 2023 г.) - Curve на сумму 60 миллионов долларов подверглась повторной атаке из-за ошибки компиляции в ее контрактном языке программирования Vyper.

Атака протокола Origin (ноябрь 2022 г.) — проект Stablecoin стоимостью 7 миллионов долларов Origin Dollar (OUSD) подвергся повторной атаке.

Атака Siren Protocol (сентябрь 2021 г.) — 3,5 миллиона долларов, пул AMM подвергается повторной атаке.

Атака Cream Finance (август 2021 г.) — 18,8 млн долларов, злоумышленники использовали уязвимость повторного входа для вторичного заимствования.

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

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

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

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

Нам нужна защита во время выполнения

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

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

Проблемы реализации защиты во время выполнения

К сожалению, дизайн EVM не поддерживает защиту во время выполнения в цепочке, потому что смарт-контракты не имеют доступа к полному контексту во время выполнения.

Как преодолеть эту проблему? Мы считаем, что необходимы следующие предпосылки:

Специальный модуль, который обеспечивает доступ ко всей информации по смарт-контрактам, включая весь контекст транзакции.

Необходимая авторизация получается из смарт-контракта, что дает модулю право отменять транзакции по мере необходимости.

Убедитесь, что функциональность модуля вступает в силу после выполнения смарт-контракта и до фиксации состояния.

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

Идея Artela состоит в том, чтобы EVM + собственное расширение, создав собственный уровень расширения WASM EVM, чтобы реализовать выход за пределы EVM.

Введение в аспектное программирование

Мы запустили Aspect Programming, платформу программирования для блокчейна Artela, которая поддерживает собственное масштабирование в блокчейне.

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

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

Как аспектное программирование реализует защиту во время выполнения

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

Аспект реализует ключевые свойства для защиты во время выполнения:

Может запускаться после выполнения смарт-контракта и перед отправкой состояния: Модули аспекта можно настроить на активацию после выполнения смарт-контракта, но до отправки состояния.

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

Возможность системных вызовов: Aspect может выполнять системные вызовы и инициировать отслеживание транзакций, когда это необходимо.

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

Реализовать Aspect для защиты от повторного входа

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

Фактический аспект «Намерение защиты контракта» может быть развернут в точке соединения «preContractCall» и «postContractCall» для предотвращения повторных атак.

preContractCall: срабатывает перед выполнением кросс-контрактного вызова.

postContractCall: срабатывает после выполнения кросс-контрактного вызова

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

В pointcut «preContractCall» Aspect отслеживает стек вызовов контракта. Если в стеке вызовов есть какие-либо повторяющиеся вызовы (имеется в виду неожиданный повторный вход в наш заблокированный вызов), аспект откатит вызов.

Разверните контракт Curve и предотвратите повторные атаки

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

Видно, что и add_liquidity, и remove_liquidity вышеуказанного контракта защищены одной и той же блокировкой повторного входа, а это означает, что если защита от повторного входа работает нормально, защищенная функция не может быть повторно введена путем изменения блокировку (например, при удалении _liquidity вызывается add_liquidity).

Скомпилируйте приведенный выше контракт с помощью компилятора vyper 0.2.15, 0.2.16 или 0.3.0 (эти версии имеют известные проблемы с защитой от повторного входа).

Затем мы развертываем приведенный выше контракт жертвы и атакуем его следующим контрактом:

Чтобы имитировать реальную атаку, метод атаки этого контракта пытается повторно ввести add_liquidity из метода remove_liquidity через его резервную функцию. Если повторный вход действительно происходит, в квитанции можно увидеть, что событие AddLiquidity регистрируется перед событием RemoveLiquidity.

Теперь воспользуемся Aspect для защиты контракта от атаки. Перед выполнением следующих действий выполните следующие действия:

1. Разверните Аспект

2. Заключить контракт жертвы с Аспектом

Если вы не знакомы с операциями Aspect, вы можете сначала ознакомиться с нашим руководством для разработчиков.

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

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

в заключение

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

Для повышения безопасности DeFi защита во время выполнения становится критически важной. Защищая протокол по принципу «черного ящика», гарантируя, что выполнение протокола соответствует его предполагаемому дизайну, он может эффективно предотвращать повторные атаки во время выполнения.

Мы разветвили контракт Curve и полностью смоделировали его недавнюю реентерабельную атаку, а также воспроизвели весь процесс более понятным образом. Используя программирование аспектов в качестве нового подхода к защите среды выполнения в цепочке, мы шаг за шагом показываем, как защитить контракты жертвы с помощью аспектов. Наша цель — помочь искоренить атаки с повторным входом, от которых могут пострадать протоколы DeFi, такие как Curve, тем самым повысив безопасность во всем пространстве DeFi.

С помощью Aspect Programming разработчики могут не только обеспечить защиту во время выполнения в цепочке в области безопасности, но и реализовать беспрецедентные инновационные варианты использования, такие как намерения, JIT и автоматизация в цепочке. Кроме того, эта общая структура, основанная на Cosmos SDK, будет поддерживать не только блокчейн Artela, но и другие блокчейны для создания собственных расширений на основе их собственных уровней выполнения.