Уязвимы ли смарт-контракты на ? В сегодняшней статье мы рассмотрим ТОП-5 возможных уязвимостей смарт-контрактов на .
Solana – быстрорастущая платформа смарт-контрактов, стабильно входящая в тройку лидеров наряду с Ethereum и Polkadot. Для разработчиков, пишущих смарт-контракты Solana, и злоумышленников, стремящихся их взломать, безопасность этих смарт-контрактов является актуальным вопросом.
Поскольку смарт-контракты – это, по сути, части программного обеспечения, выполняемые по цепочке, в Solana они называются “программами”.
Смарт-контракты SOLANA: ТОП-5 уязвимостей и подводных камней
Все платформы смарт-контрактов имеют свои причуды, которые приводят к небезопасным смарт-контрактам, и Solana не является исключением. Некоторые из наиболее распространенных уязвимостей в смарт-контрактах Solana, которые злоумышленник может использовать или взломать, включают следующее:
1. Отсутствует проверка права собственности
Смарт-контракты обычно содержат привилегированные функции, которые должны быть доступны только определенным учетным записям. Если это так, то должен проверить, что учетная запись является доверенной, прежде чем запускать эту привилегированную функциональность.
Все учетные записи Solana принадлежат смарт–контрактам – из этого правила нет исключений. Изменять данные учетных записей разрешено только контрактам. Задачей разработчиков смарт-контрактов является внедрение необходимых средств контроля авторизации, включая проверку цифровой подписи отправителя транзакции.
Структура метаданных учетной записи в Solana включает поле владельца, которое указывает открытый ключ, связанный с владельцем этой учетной записи. Чтобы подтвердить, что учетная запись является доверенной, открытый ключ, хранящийся в поле ее владельца, должен быть проверен на соответствие ожидаемым значениям.
Некоторые смарт-контракты Solana используют учетные записи конфигурации или других утилит для хранения доверенных данных или открытого ключа учетной записи администратора. Эти учетные записи должны быть предоставлены пользователями, выполняющими смарт-контракт и выполняющими определенные действия.
Однако, если контракт не подтверждает владельца учетной записи, он может быть уязвим для эксплойта. Злоумышленник может обойти контроль доступа с помощью поддельной учетной записи конфигурации, если владелец учетной записи не будет подтвержден как ожидаемый, и обмануть смарт-контракт для выполнения привилегированных операций.
Вместо того, чтобы изначально доверять определенным учетным записям, смарт-контракты Solana должны проверять, что они принадлежат владельцу контракта.
2. Отсутствие проверки подписи
Для ограниченной функциональности проверка того, что открытый ключ вызывающей учетной записи совпадает с ключом авторизованного пользователя, является важным первым шагом. Однако технически учетная запись может настроить свои данные на все, что захочет; это просто данные.
Проверка происходит, когда учетная запись подписывает операцию с помощью закрытого ключа, связанного с этим открытым ключом. Если смарт-контракту не удается проверить, что операция подписана, то любой может вызвать эту инструкцию, если его учетная запись содержит правильный открытый ключ.
Смарт-контракты Solana должны проверять, что операция подписана соответствующим закрытым ключом, прежде чем выполнять привилегированные функции.
3. Целочисленное переполнение
Rust (и другие языки программирования) хранят значения в переменных фиксированного размера. Это означает, что эти переменные могут содержать только определенный диапазон значений. Если результатом операции является значение, выходящее за пределы этого диапазона, это создает переполнение целого числа или недостаточный поток.
В режиме отладки Rust проверяет наличие переполнений и недостаточных потоков, но это неверно в режиме выпуска (который используется набором инструментов Solana BPF). Если значение выходит за пределы диапазона значений, которые может поддерживать переменная, оно будет обтекаться.
Злоумышленник может воспользоваться этим фактом, чтобы уклониться от проверки передачи ценностей. Если программа проверяет, что a + b < c и a и b не суммируются при передаче, то злоумышленник может выбрать значения a и b, чтобы обойти проверку. Позже, когда происходит передача, используется только одно значение, что означает, что оно не будет переполнено и на указанный адрес будет отправлено большое количество значений.
Целочисленное переполнение обычно является результатом небезопасной математики и небезопасных приведений между типами переменных. Если он использует проверенные версии арифметических операций и операций приведения, смарт-контракт выдаст ошибку, если произойдет переполнение / недостаточный поток, что приведет к отмене транзакции.
4. Невозможность проверки внешних программ
Смарт-контракты предназначены для взаимодействия друг с другом и вызова функций из внешних программ. Шаблоны проектирования Solana гласят, что программы, вызываемые внутри функции, должны передаваться этой функции в качестве аргумента.
Аргументы функции могут находиться под контролем пользователя, что означает, что злоумышленник может предоставить вредоносные входные данные. Передавая похожую программу в качестве аргумента уязвимой функции, злоумышленник может убедить смарт-контракт запустить эту программу (а иногда даже присвоить идентификатор вызывающей программы) вместо той, на которую они намеревались.
Подобно проверке учетных записей на основе их открытых ключей, смарт-контракты должны проверять программы, которые они вызывают, на основе их открытых ключей. Это подтверждает, что программа является той, которую смарт-контракт намеревался вызвать.
5. Отсутствует проверка структуры учетной записи
Смарт-контракт Solana может определять несколько разных учетных записей для разных целей. Эти атаки могут иметь разную структуру и содержать разные типы данных.
Данные учетной записи передаются в функцию смарт-контракта Solana в виде массива байтов, который получатель затем десериализует на основе структуры ожидаемого типа учетной записи. Это создает возможность для эксплойта, когда злоумышленник создает учетную запись одного типа и передает ее функции смарт-контракта в качестве экземпляра учетной записи другого типа.
Проверка владения учетной записью прошла бы проверку владения, если бы она была создана одной из собственных функций контракта. Однако, данные, связанные с этой учетной записью, будут интерпретироваться на основе предполагаемого типа учетной записи, что может позволить злоумышленнику устанавливать определенные значения и проходить проверки.
Эта атака использует в своих интересах тот факт, что один тип учетной записи может быть заменен другим. Если данные учетной записи начинаются с идентификатора, уникального для этого типа учетной записи, и это значение проверяется функциями, использующими эту учетную запись, то эта атака невозможна.
Защита смарт-контрактов Solana
Платформа смарт-контрактов Solana обладает некоторыми преимуществами в области безопасности, такими как использование Rust для разработки смарт-контрактов. Однако даже смарт-контракты Solana могут быть взломаны. Перед развертыванием смарт-контракта в блокчейне, смарт-контракты должны пройти аудит безопасности, чтобы найти и устранить как можно больше уязвимостей, прежде чем они смогут быть использованы злоумышленником.
