Экосистема Cosmos, признанная по всему миру одной из крупнейших и наиболее заметных блокчейн-сетей, отдает предпочтение межсетевой совместимости блокчейнов. Этот фокус является ключевым для обеспечения беспрепятственного взаимодействия между различными блокчейнами. В экосистеме действуют несколько ведущих проектов, таких как Celestia и dYdX v4, все они разработаны с использованием Cosmos SDK и протокола IBC. Растущее предпочтение разработчиков компонентам Cosmos привело к увеличению влияния проблем безопасности в экосистеме. Примером является уязвимость Dragonfruit в Cosmos SDK, которая нарушила работу множества основных публичных блокчейнов.

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

Команда CertiK посвящена укреплению безопасности сети Cosmos и широкой экосистемы Web3 через постоянные исследования и разработки. Мы рады поделиться нашими результатами и идеями с вами через регулярные отчеты о безопасности и обновления технических исследований. Если у вас есть какие-либо вопросы, наша команда всегда доступна для связи.

Здесь приведен полный текст “Руководства по безопасности экосистемы Cosmos” 👇.

Обзор Cosmos

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

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

В основе экосистемы Cosmos лежит протокол межблокчейновой связи (IBC), который соединяет приложения и протоколы различных независимых блокчейнов. Это облегчает не только беспрепятственный перевод активов и данных, но также соответствует видению Cosmos создания 'интернета блокчейнов'. Этот концепт предполагает обширную сеть автономных и легко развиваемых блокчейнов, взаимосвязанных для расширения и взаимодействия.

Участие и исследование CertiK в безопасности Cosmos

В течение длительного времени CertiK глубоко изучал экосистему Cosmos. Наша команда приобрела значительный опыт в решении проблем безопасности в этой среде. В этом отчете мы поделимся нашими идеями и открытиями о безопасности экосистемы Cosmos, сосредотачиваясь на четырех ключевых областях: безопасности Cosmos SDK, безопасности протокола IBC, безопасности CometBFT и безопасности CosmWasm. Наше обсуждение охватит все, начиная от фундаментальных компонентов экосистемы Cosmos до ее фундаментальных и прикладных цепочек. Анализируя и экстраполируя связанные проблемы, мы стремимся представить всеобъемлющий, сверху-вниз анализ критических аспектов безопасности в экосистеме Cosmos.

Учитывая сложность и разнообразие экосистемы Cosmos, она сталкивается с широким спектром проблем безопасности. В этом отчете основное внимание уделяется наиболее характерным и значительным угрозам экологической цепи Cosmos. Для получения дополнительной информации или обсуждения других аспектов безопасности мы призываем вас обратиться к инженерам по безопасности CertiK.

Фон

CometBFT: Улучшение масштабируемости межцепочек в ее основе

В основе масштабируемости Interchain лежит CometBFT, передовой алгоритм консенсуса, неотъемлемая часть обеспечения безопасности, децентрализации и целостности экосистемы Interchain. Этот алгоритм представляет собой комбинацию из двух основных компонентов: ядра CometBFT, служащего фундаментальным механизмом консенсуса, и универсального интерфейса блокчейна приложений (ABCI). Сочетая элементы PBFT (Practical Byzantine Fault Tolerance) и Bonded Proof of Stake (PoS), CometBFT синхронизирует узлы для поддержания точных записей транзакций, тем самым играя ключевую роль в консенсусе валидаторов в среде Interchain.

Космос SDK: Ускорение разработки блокчейна с помощью модульности

SDK Cosmos - это мощный инструментарий, который упрощает и ускоряет разработку блокчейна. Его модульная конструкция и возможность подключения функций позволяют разработчикам строить свои собственные блокчейны или функциональные компоненты поверх алгоритма консенсуса CometBFT. Этот подход не только облегчает разработку, но и значительно сокращает цикл разработки. Эффективность SDK подтверждается его использованием во многих проектах, включая Cronos, Kava и недавно запущенный dYdX V4. В будущем SDK Cosmos планирует улучшить свою модульность и внедрить новые функции, обеспечивая создание более сложных и модульных приложений, тем самым способствуя развитию более обширной и надежной экосистемы.

Протокол IBC: Обеспечение взаимодействия и масштабируемости между блокчейнами

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

CosmWasm: Упрощение развертывания децентрализованных приложений

CosmWasm (Cosmos WebAssembly) - это фреймворк смарт-контрактов, разработанный специально для экосистемы Cosmos. Основанный на WebAssembly, он позволяет разработчикам развертывать децентрализованные приложения без необходимости конкретных разрешений. Этот фреймворк позволяет разработчикам блокчейна отделить разработку продукта от разработки блокчейна, уменьшая нагрузку на обновления валидаторов. Особенности CosmWasm включают модульную архитектуру, интеграцию с Cosmos SDK и возможности межцепной коммуникации. Cosmos SDK и протокол IBC, будучи относительно зрелыми, широко используются в текущей экосистеме Cosmos.

Адаптация и настройка в экосистеме Космос

Для разработчиков цепочек в экосистеме Cosmos Cosmos SDK удовлетворяет большинство потребностей в настройке. Во время межцепочных операций разработчики цепочек могут настраивать свои модули IBC для специальных операций или оптимизации производительности. Хотя некоторые цепочки модифицируют базовые движки, такие как CometBFT Core, ограничения пространства не позволяют проводить подробное обсуждение таких модификаций в данном отчете. Поэтому данное исследование в основном фокусируется на технических нюансах и соображениях безопасности Cosmos SDK и протокола IBC.

Руководство по безопасности Cosmos SDK

Руководство по безопасности Cosmos SDK предоставляет всесторонний обзор аспектов безопасности Cosmos SDK, передовой фреймворк для разработки блокчейн-приложений и децентрализованных протоколов. Созданный Фондом Интерцепной, этот фреймворк является ключевым для сети Cosmos, которая представляет собой обширную сеть взаимосвязанных блокчейнов.

В своей сущности Cosmos SDK разработан для упрощения создания индивидуальных блокчейн-приложений и облегчения безшовного взаимодействия между разнообразными блокчейнами. Его заметные особенности включают в себя модульную структуру, обширные возможности настройки, интеграцию с ядром CometBFT для достижения консенсуса и внедрение интерфейсов IBC, что всё вместе способствует привлекательности для разработчиков. Одним из ключевых преимуществ Cosmos SDK является его зависимость от движка консенсуса CometBFT Core, обеспечивающего надежные меры безопасности. Этот движок играет важную роль в защите сети от злонамеренных атак и в защите активов и данных пользователей. Модульная природа SDK дает пользователям возможность легко создавать индивидуальные модули. Однако разработчикам необходимо быть бдительными, поскольку уязвимости безопасности могут всё равно возникать при развёртывании приложений с использованием Cosmos SDK.

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

Одной из ключевых точек в рамках Cosmos SDK является интерфейс ABCI, который является неотъемлемой частью экосистемы Cosmos. Этот интерфейс включает в себя четыре основных компонента: BeginBlock, EndBlock, CheckTx и DeliverTx. BeginBlock и EndBlock непосредственно участвуют в логике выполнения отдельных блоков. В отличие от них, CheckTx и DeliverTx занимаются обработкой sdk.Msg, базовой структурой данных для передачи сообщений в экосистеме Cosmos.

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

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

1. Создание транзакции: Пользователи генерируют транзакции с помощью различных инструментов, таких как интерфейсы командной строки (CLI) или клиенты фронтенда.

2. Добавление в Mempool: После создания транзакции попадают в пул памяти (mempool). Здесь узлы отправляют сообщение ABCI (Application BlockChain Interface), известное как CheckTx, на уровень приложения для проверки валидности. Транзакции проходят декодирование из байтового формата в формат Tx. Каждый sdk.Msg внутри транзакции подвергается предварительной безсостоятельной проверке с помощью функции ValidateBasic(). Кроме того, если в приложение включен anteHandler, его логика выполняется перед функцией runTx, которая приводит к выполнению функции RunMsgs() для обработки содержимого sdk.Msg. Успешная проверка CheckTx приводит к тому, что транзакция ставится в очередь в локальном пуле памяти (mempool), готовая к включению в следующий блок, и одновременно транслируется на узлы пиров через P2P.

3. Включение в предложенный блок: В начале каждого раунда инициатор собирает блок, содержащий недавние транзакции. Валидаторы, ответственные за поддержание консенсуса, либо утверждают этот блок, либо выбирают пустой блок.

4. Изменения состояния: Подобно CheckTx, процесс DeliverTx итерирует через транзакции блока. Однако он работает в режиме «Deliver», выполняя изменения состояния. MsgServiceRouter направляет различные транзакционные сообщения в соответствующие модули, где каждое сообщение обрабатывается в Msg Server. После выполнения сообщения дополнительные проверки гарантируют допустимость транзакции. Если какая-либо проверка не проходит, состояние возвращается к предыдущему. Счетчик газа отслеживает потребленный газ во время выполнения. Ошибки, связанные с газом, такие как недостаточное количество газа, приводят к откату изменений состояния, аналогично сбоям выполнения.

5. Блоковое обязательство: После получения достаточного количества голосов валидатора узел фиксирует новый блок в блокчейне. Это действие завершает переходы состояний на уровне приложения, отмечая завершение процесса транзакции.

)

[Этот раздел включает диаграмму, изображающую жизненный цикл транзакций в экосистеме Cosmos.]

[В следующем разделе представлена конкретная логика выполнения ключа ABCI в Cosmos SDK, полезная для понимания и анализа уязвимостей, обсуждаемых позже.]

)

Общие категории уязвимостей

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

)

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

1. Операция остановки цепи
2. Финансовые потери
3. Влияющий на состояние системы или нормальную работу

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

1. Отказ в обслуживании
2. Неверные настройки состояния
3. Отсутствие или неразумная верификация
4. Проблемы уникальности
5. Проблемы алгоритма консенсуса
6. Логические недочеты в реализации
7. Проблемы функционала языка

Анализ уязвимостей в экосистеме Cosmos

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

Остановка цепи: причины и типы

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

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

Cosmos SDK и CometBFT, ключевая инфраструктура в экосистеме Cosmos, используются не только базовыми цепями в Cosmos, но и различными прикладными цепями на основе их архитектуры. Все они следуют правилам интерфейса ABCI CometBFT. Фокус их поверхности атак также находится на их интерфейсе ABCI, и большинство уязвимостей безопасности, которые могут вызвать остановку цепи, являются проблемами, которые могут непосредственно повлиять на выполнение блочного кода. Поэтому пути их возникновения обычно могут быть прослежены до интерфейсов BeginBlock и EndBlock.

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

Примеры первого типа

Пример 1: Анализ уязвимости проекта SuperNova

Фон уязвимости: В процессе распределения эмиссии в рамках проекта SuperNova возникает критическая проблема из-за отсутствия проверки адреса. Это упущение может привести к сбоям в работе и, следовательно, к финансовым потерям. В частности, модуль эмиссии, который является ключевым для генерации токенов, зависит от суммы ставки. Однако этот процесс подвержен ошибкам. Например, если назначенный пул не существует или если в адрес контракта внесена ошибка, это может привести к сбоям в модуле эмиссии. Такие ошибки могут остановить всю операцию блокчейна. Кроме того, в модуле пула вознаграждений отсутствует проверка адреса контракта пула. Это упущение означает, что любой сбой в операции распределения может вызвать немедленную остановку блокчейна.

Местоположение уязвимости: Ссылка на GitHub SuperNova

Уязвимый фрагмент кода:

Путь запуска уязвимости:

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

Патч уязвимости:

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

Патч находится в модуле обработки сообщений poolincentive (x/poolincentive/types/msgs.go), а не в модуле монетопечатания. Он добавил проверку адреса к сообщению MsgCreateCandidatePool, чтобы исключить возможность неправильных адресов из корня.

Пример 2: Проект по безопасности межцепочки Космоса

Project address: Ссылка на GitHub по безопасности межцепочки Cosmos

Фон уязвимости: Валидаторы могут замедлить цепочку поставщиков, отправляя несколько сообщений AssignConsumerKey в том же блоке. В функции AssignConsumerKey в файле x/ccv/provider/keeper/key_assignment.go валидаторы могут назначать разные consumerKeys для утвержденных цепочек потребителей. AddressList consumerAddrsToPrune увеличивается на один элемент для выполнения этой операции. Поскольку этот AddressList итерируется в EndBlocker в файле x/ccv/provider/keeper/relay.go, атакующие могут использовать это для замедления цепочки поставщиков. Для этой атаки злоумышленник может создавать транзакции с несколькими сообщениями AssignConsumerKey и отправлять их в цепочку поставщиков. Кардинальность AddressList consumerAddrsToPrune будет такой же, как у отправленных сообщений AssignConsumerKey. Следовательно, выполнение EndBlocker займет больше времени и ресурсов, чем ожидалось, замедляя или даже останавливая цепочку поставщиков.

Местоположение уязвимости: Ссылка на GitHub по безопасности межцепочного взаимодействия Cosmos

Уязвимый сегмент кода:

Путь запуска уязвимости:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

Обработка принятых пакетов VSC Matured

ОбработатьVSCMaturedPacket

PruneKeyAssignments

Пример 3: Проект Quicksilver - Модуль Airdrop

Фон уязвимости: BeginBlocker и EndBlocker - это необязательные методы, которые разработчики модулей могут реализовать в своем модуле. Они запускаются в начале и в конце каждого блока соответственно. Использование сбоев для обработки ошибок в методах BeginBlock и EndBlock может привести к остановке цепочки в случае ошибок. EndBlocker не учитывал, достаточно ли у модуля токенов для завершения незавершенных роздач, что могло вызвать сбой и остановить цепочку.

Местоположение уязвимости: Ссылка на Quicksilver GitHub

Сегмент кода уязвимости:

Уязвимость патч: AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

Патч уязвимости: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

Код обработки паники был удален и заменен журналированием ошибок.

Пример 4: Проект по безопасности межцепочечной связи Cosmos

Адрес проекта: Ссылка на GitHub Cosmos Interchain Security

Фон уязвимости: Злоумышленники могут осуществить атаку отказа в обслуживании, отправляя несколько токенов на адрес вознаграждения цепочки-поставщика. В потоке выполнения EndBlocker цепочки-потребителя функция SendRewardsToProvider, определенная в x/ccv/consumer/keeper/distribution.go, извлекает баланс всех токенов в tstProviderAddr и отправляет их на цепочку-поставщика. Для этого она должна перебирать все найденные токены в адресе вознаграждения и отправлять каждый из них через IBC на цепочку-поставщика. Поскольку любой может отправлять токены на адрес вознаграждения, злоумышленники могут создавать и отправлять большое количество токенов различных denom, например, используя цепочку с модулем фабрики токенов, чтобы инициировать атаку отказа в обслуживании. Поэтому выполнение EndBlocker займет больше времени и ресурсов, чем ожидалось, замедляя или даже останавливая цепочку-потребителя.

Местоположение уязвимости: Ссылка на GitHub по безопасности межцепочечного Cosmos

Уязвимый сегмент кода:

Путь запуска уязвимости:

AppModule.EndBlock

КонецБлока

EndBlockRD

Отправить вознаграждения поставщику

Второй тип ситуации

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

Пример 1

Фон уязвимости: Cosmos SDK Security Advisory Jackfruit

Недетерминированное поведение в методе ValidateBasic модуля x/authz в Cosmos SDK может легко привести к остановке консенсуса. Структура сообщения MsgGrant в модуле x/authz включает поле Grant, которое содержит время истечения, предоставленное пользовательским определением авторизации. В процессе проверки в ValidateBasic() в структуре Grant он сравнивает свою временную информацию с информацией о локальном времени узла, а не с информацией о времени блока. Поскольку локальное время недетерминировано, метки времени могут различаться между узлами, что приводит к проблемам консенсуса.

Объявление о уязвимости:

• Ссылка на форум Cosmos 1

• Ссылка на форум Cosmos 2

• Ссылка на информацию о безопасности GitHub Cosmos SDK

Уязвимый сегмент кода:

Патч уязвимости: Ссылка на сравнение GitHub Cosmos SDK

Проблемы, такие как метки времени, возникают не только в фундаментальных компонентах, таких как Cosmos SDK, но и происходили в различных прикладных цепочках.

Пример 2

Фон уязвимости: SuperNova, проект nova

Адрес проекта: Ссылка на GitHub SuperNova

Использование time.Now() возвращает метку времени операционной системы. Местное время субъективно и, следовательно, недетерминированно. Поскольку могут быть небольшие различия в метках времени отдельных узлов, цепь может не достичь консенсуса. В модуле ICAControl функция отправки транзакции использует time.Now() для получения метки времени.

Местоположение уязвимости: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

Уязвимый сегмент кода:

Уязвимость исправлена:

Изменилось с использования локального времени на использование времени блока.

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp)

Случай Три:

Уязвимость фона: Модуль Oracle в проекте BandChain

Ссылка на проект: Репозиторий BandChain на GitHub

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

Местоположение уязвимости: BandChain GitHub Кодовый сниппет

Уязвимый сегмент кода:

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

Случай Четыре:

Фон уязвимости: Модуль управления доступом в проекте Sei Cosmos

URL проекта: Репозиторий GitHub Sei Cosmos

В нескольких случаях в репозиториях кода, связанных с Cosmos, используется тип map языка Go и его итерация. Из-за недетерминированной природы итерации map в Go это может привести к тому, что узлы достигнут различных состояний, что потенциально может вызвать проблемы согласования и, следовательно, остановить работу цепочки. Более подходящим методом было бы сортировать ключи map в срез и итерироваться по отсортированным ключам. Такие проблемы являются распространенными и связаны с применением языковых особенностей.

При реализации BuildDependencyDag в x/accesscontrol/keeper/keeper.go происходит итерация по узлам anteDepSet. Из-за недетерминированного поведения итерации по карте в Go ValidateAccessOp может привести к двум разным типам ошибок, что потенциально может привести к сбою консенсуса.

Местонахождение уязвимости: Кодовый фрагмент GitHub Sei Cosmos

Уязвимый сегмент кода:

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

потеря средств

Вопросы потери капитала часто встречаются в логической обработке sdk.Msg и сообщений IBC. Конечно, существуют также некоторые уязвимости, которые могут вызвать потерю капитала среди причин, которые могут остановить работу блокчейна. Конкретное влияние зависит от конкретной уязвимости, и здесь мы сосредотачиваемся на первом. Кроме того, поскольку IBC является очень важным компонентом экосистемы Cosmos, это неизбежно включает некоторые уязвимости в IBC. Подробности об атаках на IBC и соответствующих уязвимостях будут обсуждаться в следующей главе.

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

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

Фон уязвимости: Проект SuperNova

URL проекта: https://github.com/Carina-labs/nova

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

Местоположение уязвимости: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

Фрагмент кода уязвимости:

Путь срабатывания уязвимости:

msgServer.ЗаявитьSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

• Фон уязвимости: проект SuperNova

Адрес проекта: https://github.com/Carina-labs/nova/

Уникальность зоны не подтверждена. В зарегистрированных регионах используйте идентификатор региона, чтобы проверить уникальность базового токена (BaseDenom). BaseDenom для каждого региона должен быть уникальным. Если значение базового токена установлено неправильно, это приведет к потере средств. Прежде чем устанавливать базовый токен в RegisterZone, проект не гарантировал, что BaseDenom был уникален во всех основных зонах. В противном случае существует возможность хранения пользовательских средств в другой злонамеренной зоне, содержащей BaseDenom с тем же именем, что приведет к потере средств.

Местоположение уязвимости: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Уязвимый фрагмент кода:

Исправление ошибки: Добавлена проверка DenomDuplicateCheck

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

• Контекст уязвимости: проект Supernova

Адрес проекта: https://github.com/Carina-labs/nova/

Отсутствие обновлений статуса. В методе IcaWithdraw(), если транзакция завершается неудачно и статус версии не изменен, то WithdrawRecord будет недоступен, и соответствующие средства не могут быть выведены. Более популярное понимание заключается в том, что состояние устанавливается до SendTx, и после неудачи состояние не изменяется, что приводит к неудаче вывода средств и невозможности их повторного вывода в следующий раз.

Местоположение уязвимости: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Уязвимый фрагмент кода:

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

Влияние на состояние системы или нормальную работу

Диапазон этой категории вопросов довольно широк. Первые два типа рисков, о которых мы говорили, также могут рассматриваться как подмножества уязвимостей, которые влияют на состояние системы или нормальное функционирование. Помимо этого, более опасными являются различные логические уязвимости. В значительной степени эти уязвимости генерируют различные риски безопасности в соответствии с бизнес-логикой проекта. Однако из-за сходства в построении компонентов Cosmos SDK и их модульной природы часто возникают аналогичные ошибки в конкретных реализациях кода. Здесь мы перечисляем некоторые распространенные типы уязвимостей:

- Неполная проверка переменной в типе sdk.Msg:

Поскольку различные проекты реализовали различные производные типы на основе sdk.Msg, не все элементы существующих типов были проверены соответственно в Cosmos SDK. Это привело к пропуску проверки критически встроенных переменных, что влечет за собой определенные риски безопасности.

Пример использования: Cosmos SDK Security Advisory Barberry

Фон уязвимости: У MsgCreatePeriodicVestingAccount.ValidateBasic отсутствуют механизмы для оценки статуса учетной записи, такие как то, активна ли она. В x/auth определенном PeriodicVestingAccount атакующий мог бы инициализировать учетную запись жертвы к злонамеренно принадлежащей учетной записи. Эта учетная запись позволяет вносить депозиты, но запрещает вывод средств. Когда пользователи вносят средства на свою учетную запись, эти средства будут навсегда заблокированы, и пользователь не сможет их вывести.

Защитный патч уязвимости:

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

Уязвимый фрагмент кода:

Кроме того, проблемы на этапе ValidateBasic также присутствовали в Cosmos-SDK Security Advisory Elderflower и Cosmos-SDK Security Advisory Jackfruit. Первая столкнулась с прямым пропуском вызова ValidateBasic, в то время как вторая включала проблемы с проверкой переменной временной метки внутри сообщения. В прикладных цепях такие проблемы еще более распространены. Проекты типа ethermint, pstake-native и quicksilver столкнулись со схожими уязвимостями безопасности в своих мерах проверки обработки сообщений.

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

Общие типы уязвимостей

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

Проблемы уникальности

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

Проблемы функциональности языка

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

Сводка

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

• Обратите внимание на уязвимости инфраструктуры: Основные компоненты, такие как CometBFT и Cosmos SDK, также могут иметь уязвимости, поэтому регулярные обновления и техническое обслуживание необходимы для обеспечения безопасности.

• Быстро проверяйте сторонние библиотеки: Разработчики Cosmos часто используют сторонние библиотеки для расширения функциональности своих приложений. Эти библиотеки могут содержать потенциальные уязвимости, поэтому требуется проверка и обновление для снижения рисков.

• Будьте осторожны с злонамеренными атаками узлов: Узлы консенсуса играют важную роль в экосистеме Cosmos. Алгоритмы бизантинской толерантности к отказам этих узлов могут быть уязвимыми для атак, поэтому обеспечение безопасности узла является важным для предотвращения злонамеренного поведения.

• Рассмотрите физическую безопасность: Для обеспечения безопасности аппаратных средств и серверов, на которых работают узлы Cosmos, требуются физические меры безопасности, чтобы предотвратить несанкционированный доступ и потенциальные атаки.

• Проводить необходимые кодовые обзоры: Учитывая открытость экосистемы Cosmos SDK и CometBFT, разработчики и аудиторы должны просматривать как основной код, так и код, написанный в пользовательских модулях, чтобы выявить и исправить потенциальные проблемы безопасности.

• Обратите внимание на инструменты экосистемы: Экосистема Cosmos включает в себя множество инструментов и приложений, которые также должны пройти проверку безопасности и регулярные обновления, чтобы гарантировать их безопасность.

Руководство по безопасности протокола IBC

Этот модуль фокусируется на аспектах безопасности протокола межблокчейнового взаимодействия (IBC), важного компонента в экосистеме Cosmos. Протокол IBC служит мостом для взаимодействия между различными блокчейнами. В то время как другие межцепочные мостики предоставляют решения для конкретных изолированных проблем, протокол IBC предлагает унифицированное базовое решение и техническую поддержку для межцепочных взаимодействий. IBC - это протокол, который позволяет гетерогенным блокчейнам передавать любые данные надежным, упорядоченным и минимально доверенным образом.

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

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

Итак, как IBC удовлетворяет эти потребности и играет такую важную роль? Фундаментальные причины заключаются в том, что IBC:

1. Доверие минимизировано

2. Способен поддерживать гетерогенные блокчейны

3. Настроенный на уровне приложения

4. Зрелая, проверенная технология

Основой протокола IBC являются легкие клиенты и релеи. Цепи A и B, общающиеся через IBC, каждая обладает легкими клиентами другого учетного реестра. Цепь A, не нуждаясь в доверии к третьей стороне, может достигнуть консенсуса по состоянию цепи B, верифицируя заголовки ее блоков. Цепи, взаимодействующие через IBC (особенно модули), не отправляют сообщения друг другу напрямую. Вместо этого цепь A синхронизирует определенные сообщения в пакет данных со своим состоянием. Впоследствии релеи обнаруживают эти пакеты данных и передают их на целевую цепь.

В целом протокол IBC можно разделить на два уровня: IBC TAO и IBC APP.

• IBC TAO: Определяет стандарты передачи пакетов данных, аутентификации и упорядочивания, в основном, на уровне инфраструктуры. В ICS (Стандарты межцепочных взаимодействий) это включает в себя основные, клиентские и ретрансляторские категории.

• IBC APP: Определяет стандарты для обработчиков приложений пакетов данных, передаваемых через транспортный уровень. Сюда входят, в том числе, но не ограничиваясь, передачи обращаемых токенов (ICS-20), передачи необращаемых токенов (ICS-721) и межцепочечные счета (ICS-27), их можно найти в категории приложений ICS.

Протокол IBC (из портала разработчиков Cosmos)

Протокол межблокчейновой коммуникации (IBC) является угловым камнем видения экосистемы Cosmos о "Интернете блокчейнов". В этом контексте выборы дизайна IBC влияют на стандарты TCP/IP. Подобно тому, как TCP/IP устанавливает стандарты для компьютерной коммуникации, IBC определяет набор универсальных абстракций, которые позволяют блокчейнам обмениваться данными между собой. Как и TCP/IP, IBC не ограничивает содержание пакетов данных, передаваемых через сеть. Кроме того, подобно тому, как прикладные протоколы, такие как HTTP и SMTP, построены на основе TCP/IP, приложения, например, стандартизированные передачи активов/нефункциональных активов или вызовы смарт-контрактов между цепями, также используют протокол IBC в качестве основного уровня.

Основные проблемы, которые в настоящее время наблюдаются с протоколом IBC, связаны с передачей канала и обработкой пакетов. Были значительные проблемы с проверкой доказательств, но они относительно менее распространены. В этой статье рассматриваются общие проблемы протокола IBC. Благодаря модульному дизайну протокола IBC разработчикам приложений IBC не нужно беспокоиться о деталях, таких как клиенты, подключения и проверка доказательств. Однако им необходимо реализовать интерфейс IBCModule и соответствующие методы обработки хранителя. Поэтому многие проблемы, связанные с протоколом IBC, возникают в кодовых путях интерфейсов IBCModule для приема и обработки пакетов (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket и т. д.).

Общие классификации уязвимостей

В экосистеме Cosmos протокол IBC служит в качестве связующего центра. Типы уязвимостей, связанных с протоколом IBC, разнообразны и сложны из-за тесной интеграции его реализаций с модулями, такими как Cosmos-SDK и CometBFT. Кроме того, поскольку IBC в основном используется в экосистеме Cosmos, его основным языком программирования является Golang, как подробно описано в документации ibc-go.

Из-за ограничений места в этой статье не углубляется в детальный анализ каждого аспекта и компонента протокола IBC. Вместо этого он классифицирует некоторые из существующих уязвимостей безопасности. Для более детального и всестороннего анализа вы можете обратиться к нашим инженерам по безопасности CertiK для обсуждения.

Общие классификации уязвимостей:

1. Уязвимости в названиях

   ① Уязвимости обработки строк

   ② Уязвимости обработки байткода

2. Уязвимости процесса передачи

   ① Уязвимости порядка пакетов

   ② Уязвимости тайм-аута пакета

   ③ Уязвимости аутентификации пакета

   ④ Другие уязвимости пакетов

3. Логические уязвимости

   ① Обновление уязвимостей государства

   ② Уязвимости голосования и консенсуса

   ③ Другие Логические Уязвимости

4. Уязвимости потребления газа

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

Анализ уязвимостей

Формулирование протокола IBC

Case Study 1: Протокол ICS-07, Логическая Уязвимость

Фон уязвимости: Неверное использование периода отвязки

В коде существует следующая проверка:

if currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod

Согласно модели безопасности Tendermint, для блока (заголовка) в момент времени t валидаторы в NextValidators должны корректно работать до t+TrustingPeriod. После этого они могут демонстрировать другое поведение. Однако здесь проверяется UnbondingPeriod, а не TrustingPeriod, где UnbondingPeriod > TrustingPeriod. Если крайний срок consState находится между TrustingPeriod и UnbondingPeriod, то этот заголовок будет принят в качестве эталона для проверки одного из конфликтующих заголовков, представляющих собой неправомерное поведение. В течение этого периода валидаторы в consState.NextValidators больше не считаются надежными, и враждебно настроенные бывшие валидаторы могут закрыть клиент без какого-либо риска.

Адрес проекта: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

Местоположение уязвимости:

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

Уязвимый фрагмент кода:

функция определения протокола

Код

Внедрение протокола IBC

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

1. Недопонимания и нестандартные проблемы в реализации протокола.

2. Ошибки в настройках протокола.

Неоднозначности и нестандартные проблемы в реализации протокола

Case Study 1: Протокол ICS-20, уязвимость в названии

Фон уязвимости: Конфликт кастодиального адреса. GetEscrowAddress()Функция генерирует усеченный SHA256 из 20 байт (идентификатор порта + идентификатор канала). У этого метода три проблемы:

1. Отсутствие разделения домена между портами и каналами. Метод объединения строк не разделяет домены порта и канала. Например, комбинации порта/канала («transfer», «channel») и («trans», «ferchannel») приведут к одному и тому же адресу кастодиал, т. е. усеченному SHA256 («transferchannel»). Если определенным модулям с библиотечными функциями разрешено выбирать идентификаторы порта и канала, могут возникнуть уязвимости.

2. Конфликты между адресами учетной записи модуля. В предварительном изображении SHA-256 используются произвольные буквенно-цифровые строки с размером пост-изображения 160 бит. Это небольшое пост-изображение в сочетании с быстрой хэш-функцией делает атаку дня рождения выполнимой, так как его безопасность снижается только до 80 бит. Это означает, что приблизительно 2^80 попыток требуется для нахождения коллизии между двумя разными адресами кастодиальных учетных записей. В 2018 году был проведен подробный анализ стоимости атаки на усечение SHA256 в контексте Tendermint, доказывающий, что такая атака выполнима с точки зрения стоимости. Нахождение коллизии означает, что две разные кастодиальные учетные записи сопоставляются с одним и тем же адресом учетной записи. Это может привести к рискам кражи средств с кастодиальных учетных записей. Дополнительные сведения см. в ICS20 GetEscrowAddress предварительное изображение домена пересекается с открытыми ключамиT:BUG.

3. Конфликты между адресами модуля и не-модуля. Построение общедоступных адресов счетов такое же, как 20-байтовый SHA-256 открытых ключей Ed25519. Хотя 160-битная защита достаточна для предотвращения атак столкновения на конкретные общедоступные адреса, безопасность от атак дня рождения составляет всего 80 бит. Эта ситуация напоминает полуденежную атаку, где один адрес генерируется быстрым SHA-256, а другой адрес генерируется относительно медленными вычислениями открытых ключей Ed25519. Хотя эта ситуация более безопасна, она все еще представляет потенциальные угрозы для кастодиальных и общедоступных счетов.

Адрес проекта: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

Местоположение уязвимости: https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

Уязвимый фрагмент кода:

Проблема с настройкой протокола ошибки

• Case 1: IBC Security Advisory Dragonberry, уязвимость процесса передачи

Фон уязвимости: IBC будет использовать структуру Packet при обработке пакетов данных приложений. Согласно механизму тайм-аута, синхронным и асинхронным механизмам подтверждения и соответствующему процессу проверки сертификации, пакет данных будет разделен на два процесса выполнения:

1. Обычная ситуация: Успех в пределах времени ожидания

2. Ситуация тайм-аута: сбой тайм-аута

Диаграмма потока передачи пакета заявки IBC

Когда происходит тайм-аут, это означает, что передача не удалась, и протокол IBC инициирует процесс возврата средств. Следует отметить, что у IBC есть настраиваемый пользователем механизм тайм-аута. Уязвимость Dragonberry происходит от ICS-23 (IBC). Основная причина этой уязвимости заключается в том, что пользователи могут подделывать доказательства отсутствия в процессе верификации (то есть ложные доказательства того, что пакеты данных не были получены), тем самым обходя проверки безопасности и подделывая «разумную» ситуацию тайм-аута IBC для обмана протокола IBC, вызывая повторителю отправлять тайм-аут пакеты с ложными сертификатами и возможно эскалировать до проблемы двойного расходования ICS-20. Конкретный процесс запуска уязвимости можно увидеть на рисунке ниже.

Принцип уязвимости Dragonberry на схеме потока

Адрес проекта: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

Местоположение уязвимости: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Уязвимый фрагмент кода:

• Case 2: IBC Security Advisory Huckleberry, уязвимость процесса передачи

Фон уязвимости: UnreceivedPackets конструирует ответ, находя соответствующий прием пакета для каждого номера последовательности, включенного в запрос. Это работает только для каналов с нарушенным порядком, поскольку упорядоченные каналы используют nextSequenceRecv вместо приемов пакетов. Следовательно, на упорядоченном канале запрос номера последовательности через GetPacketReceipt не найдет прием внутри него.

Серьезность этой проблемы невелика, потому что канал, передаваемый ICS-20 FT, в основном находится в беспорядке, и ретранслятор не полагается на этот конечный точку grpc для определения того, какие пакеты вызывают тайм-аут. Однако, если в целевой цепи большое количество пакетов, и для передачи IBC настроен упорядоченный канал, а ответ grpc не разбит на страницы, это может создать риск снижения производительности служебного узла или даже его сбоя. Специфика процесса, вызывающего триггер, можно увидеть на рисунке ниже.

Диаграмма потока принципа уязвимости Huckleberry

Адрес проекта: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

Местоположение уязвимости: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

Уязвимый фрагмент кода:

Применение и расширение протокола IBC

• Case 1: уязвимость в воздушной капле, уязвимость логики

Фон уязвимости: Функция Попробуйте Обновить Представление Вознагражденияпреобразует адрес отправителя пакета IBC в адрес Stride с именемsenderStrideAddress, и извлекает идентификатор воздушного капельи новый адрес воздушного капельникаnewStrideAddressиз метаданных пакета. Затем вызываетОбновитьAirdropAddressобновитьадрес отправителя шага и ЗаписьПретензииС обновлением ЗаписьПретензии, newStrideAddressсможет запросить воздушную каплю. Однако эта функция обновления только проверяет, пустой ли адрес отправителя запроса, и не проверяетновыйАдресStrideПоскольку IBC позволяет одиночным машинным подключениям реализовывать цепи, поддерживаемые IBC, это создает риск безопасности, при котором возможно обновление любого другого адреса учетной записи как адреса для воздушного капельника.

Адрес проекта: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

Местоположение уязвимости: https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

Уязвимый фрагмент кода:

• Case 2: уязвимость модуля neutron ibc, уязвимость потребления газа

Фон уязвимости: В контексте смарт-контрактов возникает проблема с проверкой комиссий для подтверждения или тайм-аута событий межблокчейн-коммуникации (IBC). Этот недочет позволяет зловредным смарт-контрактам вызывать сбой 'ErrorOutOfGas'. Этот сбой происходит во время обработки сообщений 'OnAcknowledgementPacket' и 'OnTimeoutPacket'. Когда происходит эта ошибка, невозможно решить ее обычным методом 'outOfGasRecovery'. В результате затронутые транзакции не удается включить в блокчейн. Это отказ может привести к тому, что межблокчейн-ретрансляторы будут пытаться повторно отправить эти сообщения. Такие повторные отправки могут привести к финансовым потерям для ретрансляторов и перегрузке сети из-за избыточного количества необработанных ('заброшенных') пакетов, что создает риск для стабильности сети.

Адрес проекта: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

Местоположение уязвимости:

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

Уязвимый фрагмент кода:

Краткое изложение

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

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

Вывод

Наше исследование безопасности экосистемы Cosmos, включающее в себя детальные проверки, обобщения и категоризации, сосредоточено вокруг ее двух наиболее критических компонентов: Cosmos SDK и протокола IBC. Исходя из нашего обширного практического опыта, мы составили обширную коллекцию общих знаний по аудиту.

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

Несмотря на эти препятствия, мы оптимистичны. Документируя и анализируя общие сценарии и проблемы безопасности, как мы сделали в этом отчете, мы готовим почву для постепенного улучшения общей системы безопасности в разнообразной экосистеме Cosmos.

Disclaimer:

1. Эта статья перепечатана с [CertiK]. Все авторские права принадлежат оригинальному автору [CertiK]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно разберутся с этим.
2. Отказ от ответственности за обязательства: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.