Объяснение реентерабельных атак в смарт-контрактах

Потенциальные уязвимости в смарт-контрактах

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

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

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

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

Как работают повторные атаки

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

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

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

Давайте разберем, как работают повторные атаки, на упрощенном примере:

Смарт-контракт с функцией «вывода»

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

Взаимодействие с пользователем и выполнение функций

Пользователь самостоятельно инициирует вывод средств со своего цифрового кошелька. Используя функцию вывода средств, они вводят указанную сумму, которую хотят снять.

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

Внешний вызов

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

Рекурсивный вызов

Если код внешнего контракта содержит функцию, позволяющую ему еще раз вызвать исходный контракт, например переопределенную функцию «вывода», такая настройка приводит к рекурсивному циклу. Следовательно, метод «вывода» может запускаться неоднократно до его завершения.

Реентерабельность эксплуатации

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

Резервная функция

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

Государственное манипулирование и неоднократный вывод средств

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

Как смягчить атаки повторного входа

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

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

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

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