Back to Blog

Безопасность экосистемы Solana (7) — Смешение типов

29 апреля 2022 г.
4 min read

0. Обзор

1. Обзор

В предыдущем блоге мы представили реализацию общей мультиподписи. В этом посте мы обсудим еще одну проблему безопасности — подмену типов (Type Confusion).

2. Десериализация/Сериализация

В Solana состояния программ хранятся в аккаунтах. Проблема подмены типов возникает во время десериализации/сериализации данных аккаунтов. Логика программы обычно опирается на структуры данных. Однако программа может не проверять тип аккаунтов должным образом в процессе десериализации/сериализации. Это может быть использовано злоумышленниками, что приведет к непредвиденным потерям.

3. Обзор кода (Подмена типов)

Далее мы проиллюстрируем проблему подмены типов на простом примере программы. Тестовый код можно найти здесь.

В тестовой программе мы реализовали две структуры данных: User и Metadata. Обе они записывают открытый ключ аккаунта (разных аккаунтов).

Программа имеет три различные инструкции. Инструкция InitializeUser предназначена для создания аккаунта User и установки авторизованного аккаунта (т.е. authority). Аналогично, инструкция InitializeMeta вызывается для создания аккаунта MetaData и установки обычного аккаунта (т.е. account). Инструкция Test демонстрирует, что злоумышленник может обойти логику верификации программы и провести атаку с помощью контролируемого аккаунта MetaData.

Давайте разберем инструкцию Test(). Программа гарантирует, что владельцем переданного аккаунта User является сама программа (строки 86–89). После десериализации (строка 92) программа сравнивает открытый ключ переданного аккаунта authority с открытым ключом, хранящимся в аккаунте User. Если они не совпадают, программа делает откат (строки 93–96). Последняя проверка гарантирует, что аккаунт authority подписал транзакцию. Однако, если злоумышленник передаст контролируемый им аккаунт Metadata, все проверки все равно могут быть обойдены. Причина в том, что программа не проверяет тип аккаунтов. Она получает массив байтов и десериализует его непосредственно в типы структур, определенные в программе.

Мы развернули тестовую программу для дальнейшей проверки, её можно найти по этой ссылке.

3.1 Отправка транзакции

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

Сначала мы вызываем InitializeUser и InitializeMeta. Обратите внимание, что мы установили наш собственный открытый ключ в качестве account, хранящегося в аккаунте Metadata.

В функции test() мы передаем аккаунт Metadata в качестве аккаунта User, а наш собственный аккаунт — как authority_info (строки 347–348). Программа десериализовала Metadata как структуру User, и все проверки были обойдены.

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

4. Итоги

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

Читать другие статьи этой серии:


О компании BlockSec

BlockSec — передовая компания в сфере безопасности блокчейнов, основанная в 2021 году группой всемирно известных экспертов по безопасности. Компания стремится повысить безопасность и удобство использования развивающегося мира Web3, чтобы способствовать его массовому внедрению. Для этого BlockSec предоставляет услуги аудита безопасности смарт-контрактов и EVM-сетей, платформу Phalcon для разработки систем безопасности и проактивной блокировки угроз, платформу MetaSleuth для отслеживания и расследования транзакций, а также расширение MetaSuites для эффективной работы Web3-разработчиков в криптомире.

На сегодняшний день компания обслужила более 300 уважаемых клиентов, таких как MetaMask, Uniswap Foundation, Compound, Forta и PancakeSwap, и получила десятки миллионов долларов США в рамках двух раундов финансирования от выдающихся инвесторов, включая Matrix Partners, Vitalbridge Capital и Fenbushi Capital.

Официальный сайт: https://blocksec.com/

Официальный аккаунт в Twitter: https://twitter.com/BlockSecTeam

Sign up for the latest updates
Как решение BlockSec по обеспечению безопасности платежей помогает организациям оставаться защищёнными в эпоху ИИ
Security Services

Как решение BlockSec по обеспечению безопасности платежей помогает организациям оставаться защищёнными в эпоху ИИ

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

Потери около 5,57 млн USD: атаки на X100 Freezer и NEM | Еженедельный обзор BlockSec
Security Insights

Потери около 5,57 млн USD: атаки на X100 Freezer и NEM | Еженедельный обзор BlockSec

Этот еженедельный отчёт охватывает два инцидента безопасности в сетях Ethereum и BNB Chain за период 19.10.2026–25.10.2026. В нём рассматриваются захват управления X100 Freezer, профинансированный с помощью флеш-кредита, и ошибка при расчёте налога, затронувшая пул ликвидности токена NEM в сети BNB Chain. Оценочные потери в рамках отчёта составляют в общей сложности около 5,57 млн USD: ~4,75 млн USD по рассматриваемой транзакции X100 и ~820 тыс. USD в результате инцидента с пулом NEM. В эту сумму не входят отдельно опубликованные данные о последующих выводах средств из X100.

Потери на сумму около 3,87 млн USD: взломы Autheo Network и UNCX | Еженедельный обзор BlockSec
Security Insights

Потери на сумму около 3,87 млн USD: взломы Autheo Network и UNCX | Еженедельный обзор BlockSec

В этом еженедельном отчёте рассматриваются 3 инцидента безопасности за период 12.10.2026–18.10.2026. Общий оценочный ущерб составил около 3,87 млн USD. Ущерб Autheo Network от компрометации закрытого ключа составил примерно 1,76 млн USD, Qubic Wallet потерял примерно 1,30 млн USD из-за ненадёжной генерации seed, а ошибка учёта в контрактах Smart Token Vesting V2 сети UNCX Network на Ethereum, BNB Chain, Base и Robinhood Chain привела к ущербу примерно в 807 тыс. USD. В подробном анализе инцидента UNCX объясняется, как некорректный расчёт совокупного количества долей смешивал транши вестинга, созданные при разных соотношениях токенов и долей, и позволял выводить из общих пулов больше положенного.

Безопасность экосистемы Solana (7) — Смешение типов