Уязвимости смарт-контрактов. Reentrancy.
Пора узнать что-то новое.
Сегодня речь пойдет о Reentrancy, занимающее первое место в списке занимает уязвимость типа Reentrancy, также известная как рекурсивный вызов. Проблема кроется в том, что уязвимый контракт совершает вызов к другому контракту, при этом внешний контракт может делать ответный вызов функций уязвимого контракта внутри начального вызова. Классический пример уязвимости Reentrancy возникает в контрактах на Ethereum. Контракты могут взаимодействовать с другими контрактами, вызывая методы этих контрактов. Если контракт не правильно управляет своим состоянием, злоумышленник может использовать эту уязвимость, вызывая функцию контракта снова и снова, внедряя свой код между каждым вызовом. Это позволяет злоумышленнику манипулировать состоянием контракта и, в конечном счете, получить несанкционированный доступ к средствам или данных. Давайте рассмотрим подобный пример. Написал простой смарт-контракт который будем атаковать.
В этом примере контракта ReentrancyExample функция withdraw позволяет пользователям снимать средства со своего баланса. Однако, эта функция уязвима к Reentrancy атаке. Злоумышленник может создать свой контракт MaliciousContract и вызвать функцию attack, передавая значение средств. При вызове withdraw, функция MaliciousContract.receive будет вызываться повторно до тех пор, пока баланс в ReentrancyExample не будет исчерпан. Это позволяет злоумышленнику совершать несанкционированные вызовы и получать средства из контракта ReentrancyExample.
Уязвимость Reentrancy возникает из-за несогласованного состояния и неадекватного управления блокировками или флагами во время выполнения функций. Когда контракт вызывает внешнюю функцию, она может приостановиться и возобновиться позже. Если состояние контракта изменяется между этими вызовами, может возникнуть уязвимость Reentrancy. А теперь разберем рабочий смарт контракт. Я проводил аудит смарт-контракта для управления цифровыми активами для компании Н, вот некоторый кусок контракта. Давайте разберем его.
В этом контракте AssetManagement реализована система управления цифровыми активами. Контракт позволяет добавлять, обновлять, удалять и получать информацию об активах.
Теперь давайте рассмотрим потенциальный взлом контракта. Предположим, что у нас есть злонамеренный контракт, который вызывает функцию updateAsset с намерением изменить количество активов:
В этом злонамеренном контракте MaliciousContract мы используем адрес уязвимого контракта AssetManagement и вызываем его функцию updateAsset. Однако, злонамеренный контракт может передать некорректные параметры, что может привести к несанкционированным изменениям активов, таким как увеличение или уменьшение их количества без надлежащей проверки.
Исходя из полученных данных, можно сделать следующие выводы относительно уязвимости Reentrancy в смарт-контрактах Ethereum:
- Уязвимость реэнтранси является серьезной проблемой в смарт-контрактах Ethereum и приводит к возможности несанкционированного повторного вызова функций контракта, что может привести к нежелательным результатам и потере средств.
- Злонамеренные пользователи могут использовать уязвимости реэнтранси для проведения атак на контракты и украсть средства или изменить их работу в свою пользу.
- Проекты на Ethereum должны уделять должное внимание безопасности и проводить тщательное тестирование смарт-контрактов, чтобы исключить возможность уязвимости реэнтранси.
- Разработчики могут использовать комбинацию статического и динамического анализа для выявления уязвимостей реэнтранси в своих смарт-контрактах и обеспечения их защиты.
- Ethereum сообщество постоянно работает над улучшением безопасности платформы и разрабатывает обновления, которые исправляют известные уязвимости, включая реэнтранси.
Общая рекомендация для всех разработчиков на Ethereum - обращайте особое внимание на проверку безопасности своих смарт-контрактов и следуйте bewst practices-рекомендациям, чтобы предотвратить возможные уязвимости и обеспечить надежность своих проектов.