Екосистема Космосу, відома у всьому світі як одна з найбільших та найвідоміших блокчейн-мереж, надає перевагу міжопераційності блокчейнів. Цей фокус є ключовим для полегшення безперервного зв'язку між різними блокчейнами. У екосистемі працюють кілька провідних проектів, таких як Celestia та dYdX v4, розроблені за допомогою Cosmos SDK та протоколу IBC. Ростуча вподобаність розробників до компонентів Cosmos призвела до збільшення впливу проблем безпеки в екосистемі. Ілюстрацією цього є уразливість Dragonfruit в Cosmos SDK, яка нарушила операції в численних популярних громадських блокчейнах.

Зважаючи на децентралізований характер основних компонентів Cosmos, розробники часто змушені адаптувати та розширювати ці компоненти на основі конкретних функціональних потреб. Це призводить до фрагментації проблем безпеки в екосистемі Cosmos. Внаслідок цього виникає нагальна потреба в систематичному підході до розуміння та вирішення цих проблем безпеки. Метою цієї статті є надання комплексного аналізу поточного пейзажу безпеки в екосистемі Cosmos та визначення ефективних стратегій реагування.

Команда CertiK присвячена підсиленню безпеки мережі Cosmos та більш широкої екосистеми Web3 через постійні дослідження та розробку. Ми з нетерпінням ділимося нашими висновками та уявленнями з вами через регулярні звіти з безпеки та технічні оновлення досліджень. Якщо у вас є будь-які запитання, наша команда завжди доступна для зв'язку.

Ось повний текст "Керівництва з безпеки екосистеми Cosmos" 👇.

Огляд Космосу

Вважаючи одним з найвидатніших біткойн-екосистем у світі, Космос виділяється своєю відкритою, масштабованою та міжланцюжковою мережевою спроможністю. Розроблений командою CometBFT, спочатку відомою як Tendermint, Космос має на меті усунути інформаційні силоси та сприяти взаємодії між різноманітними блокчейнами. У час, коли існує кілька мереж блокчейнів, потреба в міжланцюжковій взаємодії більш актуальна, ніж будь-коли.

Cosmos відрізняється тим, що пропонує ефективну модель міжланцюжкової взаємодії, особливо корисну для публічних ланцюжків з конкретними вертикальними акцентами. Його модульна інфраструктура блокчейну надає розробникам додатків можливість вибору та використання публічних ланцюжків, які відповідають їх конкретним вимогам.

У центрі екосистеми Cosmos знаходиться протокол міжблокчейн-комунікації (IBC), який з'єднує додатки та протоколи різних незалежних блокчейнів. Це сприяє не лише безперервному перекладу активів та даних, але й відповідає візії Cosmos щодо створення 'інтернету блокчейнів'. Ця концепція передбачає велику мережу автономних та легко розвиваються блокчейнів, які взаємодіють для розширення та взаємодії.

Участь та дослідження CertiK у безпеці Cosmos

Протягом тривалого часу CertiK глибоко досліджувала екосистему Cosmos. Наша команда набула значного досвіду у вирішенні проблем безпеки в цьому середовищі. У цьому звіті ми поділимося нашими уявленнями та відкриттями щодо безпеки екосистеми Cosmos, зосереджуючись на чотирьох ключових областях: безпека Cosmos SDK, безпека протоколу IBC, безпека CometBFT та безпека CosmWasm. Наша дискусія охопить все, від фундаментальних компонентів екосистеми Cosmos до її фундаментальних та прикладних ланцюжків. Досліджуючи та узагальнюючи пов'язані питання, ми маємо на меті запропонувати комплексний, від фундаменту до верху, аналіз критичних аспектів безпеки в екосистемі Cosmos.

З урахуванням складності та різноманітності екосистеми Космосу вона стикається з широким спектром викликів у сфері безпеки. Цей звіт переважно концентрується на найхарактерніших та найважливіших загрозах для екологічного ланцюжка Космосу. Для отримання додаткової інформації або обговорень інших аспектів безпеки ми радимо звертатися до інженерів з безпеки CertiK.

Фон

CometBFT: Підвищення масштабованості міжланцюжкової взаємодії на своєму ядрі

У самому серці масштабованості міжланцюга лежить CometBFT, передовий алгоритм консенсусу, який є невід'ємною частиною забезпечення безпеки, децентралізації та цілісності інтерланцюгової екосистеми. Цей алгоритм є комбінацією двох основних компонентів: CometBFT Core, який виступає як фундаментальний рушій консенсусу, та універсальний інтерфейс ланцюжка блоків застосунків (ABCI). Комбінуючи елементи PBFT (Практична Візантійська Толерантність до Вад) та Bonded Proof of Stake (PoS), CometBFT синхронізує вузли для підтримки точних записів транзакцій, відтак відіграючи важливу роль у консенсусі валідаторів у середовищі міжланцюга.

Космос SDK: прискорення розвитку блокчейну за допомогою модульності

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

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

Протокол міжблокчейн-зв'язку (IBC) відіграє ключову роль у забезпеченні безпечного, децентралізованого та бездозвільного передавання даних між блокчейнами всередині мережі Cosmos. Оскільки Cosmos є децентралізованою мережею, що складається з кількох незалежних та паралельних блокчейнів, які з'єднані за допомогою технології реле, роль протоколу IBC у покращенні масштабованості та взаємодії є центральною. Поточна увага Фонду Міжланцюжкового фонду сконцентрована на поліпшенні цих аспектів протоколу IBC з метою зміцнення безшовної взаємодії між блокчейнами, додатками та смарт-контрактами всередині екосистеми Cosmos.

CosmWasm: Забезпечення деплоя децентралізованих додатків

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

Адаптація та налаштування в екосистемі Cosmos

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

Посібник з безпеки Cosmos SDK

Керівництво з безпеки Cosmos SDK надає всебічний огляд аспектів безпеки Cosmos SDK, передового фреймворку для розробки блокчейн-додатків та децентралізованих протоколів. Створений Фондом Міжланцюжкового Взаємодії, цей фреймворк є ключовим для мережі Cosmos, яка є розповзаною мережею взаємопов'язаних блокчейнів.

За своєю суттю Cosmos SDK призначений для спрощення створення індивідуальних блокчейн-додатків, одночасно сприяючи безперебійній взаємодії між різноманітними блокчейнами. Його помітні особливості включають модульну структуру, широкі можливості налаштування, інтеграцію з CometBFT Core для досягнення консенсусу та реалізацію інтерфейсів IBC, що сприяє його привабливості для розробників. Ключовою перевагою Cosmos SDK є його залежність від механізму консенсусу CometBFT Core, який забезпечує надійні заходи безпеки. Цей механізм відіграє життєво важливу роль у захисті мережі від зловмисних атак і в захисті активів і даних користувачів. Модульний характер SDK дозволяє користувачам з легкістю створювати індивідуальні модулі. Однак розробники повинні бути пильними, оскільки під час розгортання додатків за допомогою Cosmos SDK все ще можуть виникати вразливості безпеки.

З точки зору аудиту безпеки важливо ретельно оцінити потенційні загрози безпеки з різних перспектив. Натомість у дослідженні безпеки акцент зміщується на виявлення вразливостей, які можуть мати значні наслідки. Цей підхід спрямований на швидке пом'якшення основних загроз безпеці, тим самим надаючи більш ефективну допомогу службам, які інтегрують SDK. Важливо ідентифікувати та досліджувати вразливості, які становлять серйозні ризики та мають широкі наслідки.

Центральною точкою в рамках Cosmos SDK є інтерфейс ABCI, який є неот'ємною частиною екосистеми Cosmos. Цей інтерфейс складається з чотирьох ключових компонентів: BeginBlock, EndBlock, CheckTx та DeliverTx. BeginBlock та EndBlock безпосередньо беруть участь в логіці виконання окремих блоків. У свою чергу, CheckTx та DeliverTx стосуються обробки sdk.Msg, базової структури даних для передачі повідомлень в межах екосистеми Cosmos.

Для розуміння та вирішення зазначених вразливостей безпеки спочатку слід осмислити цикл життя транзакцій у космосі екосистеми. Транзакції походять від користувацьких агентів, де вони створюються, підписуються, а потім відправляються на вузли блокчейну. Вузли використовують метод CheckTx для перевірки деталей транзакцій, таких як підписи, баланс відправника, послідовність транзакцій та газ, наданий. Дійсні транзакції ставляться в чергу в мемпул, очікуючи включення в блок, тоді як недійсні відхиляються, з повідомленнями про помилку, які передаються користувачам. Під час обробки блоку метод DeliverTx застосовується для забезпечення консистентності та детермінізму транзакцій.

У Cosmos SDK, життєвий цикл транзакції - це багатоступінчастий процес, який охоплює створення, валідацію, включення в блок, зміни стану та остаточне зобов'язання. Цей процес може бути описаний наступними кроками:

1. Створення транзакції: Користувачі генерують транзакції за допомогою різних інструментів, таких як інтерфейси командного рядка (CLI) або клієнти фронтенду.

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

3. Включення у запропонований блок: Під час початку кожного раунду пропозиція збирає блок, що містить останні операції. Валідатори, які відповідають за забезпечення згоди, або схвалюють цей блок, або вибирають порожній блок.

4. Зміни стану: Подібно до CheckTx, процес DeliverTx перебирає транзакції блоків. Однак він працює в режимі «Доставка», виконуючи зміни стану. MsgServiceRouter спрямовує різні повідомлення про транзакції до відповідних модулів, де кожне повідомлення обробляється на сервері MSG. Після виконання повідомлення подальші перевірки перевіряють валідність транзакції. Якщо будь-яка перевірка не вдається, стан повертається до попереднього стану. Газовий лічильник відстежує спожитий газ під час виконання. Помилки, пов'язані з газом, такі як недостатня кількість газу, призводять до зворотних змін стану, подібно до помилок виконання.

5. Блокування зобов'язань: Після отримання достатньо голосів валідатора вузол заносить новий блок до блокчейну. Ця дія завершує переходи стану на рівні застосунку, позначаючи завершення процесу транзакції.

)

[У цьому розділі наведено діаграму, що зображує життєвий цикл транзакцій у космічній екосистемі.]

[Наступний розділ надає конкретну логіку виконання ключа ABCI в Cosmos SDK, корисну для розуміння та аналізу вразливостей, про які пізніше буде йтися.]

)

Загальні категорії вразливостей

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

)

Беручи до уваги рівень небезпеки та масштаб впливу, ми головним чином зосереджуємося на критичних та серйозних уразливостях безпеки, які, як правило, можуть викликати наступні ризики:

1. Операція зупинки ланцюга
2. Фінансові втрати
3. Впливаючи на стан системи або нормальну роботу

Причини цих небезпек часто є наступні типи вразливостей безпеки:

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

Аналіз вразливостей у космічному екосистемі

Екосистема Cosmos, відома своєю модульною структурою, часто зіштовхується з взаємним використанням та взаємним викликом модулів в межах своїх ланцюгів. Ця складність призводить до ситуацій, коли шлях виклику вразливості та змінні місця розташування несумісні. При розумінні цих вразливостей важливо не тільки враховувати шлях виклику, але й контрольований шлях критичних змінних вразливості. Ця подвійна увага сприяє кращому визначенню та категоризації моделі вразливості.

Операція зупинки ланцюга: причини та типи

Зупинка ланцюга зазвичай відбувається через проблеми, які виникають під час виконання одного блоку. Однак історія Cosmos включає випадки, коли потрібно було активно зупиняти ланцюг для виправлення уразливостей безпеки консенсусу. Ці проблеми поділяються на дві відмінні категорії.

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

SDK Cosmos та 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: Проект забезпечення безпеки міжланцюгового Cosmos

Адреса проекту: Посилання на GitHub з надійністю міжцепочкової системи Cosmos

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

Місце вразливості: Космос Міжланцюжкова Безпека Посилання на GitHub

Вразливий сегмент коду:

Шлях спрацювання вразливості:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

Обробка ведучих пакетів VSC, які дозріли

Обробити пакет, що досяг визначеного терміну

ВидалитиKeyAssignments

Приклад 3: Проект Quicksilver - Модуль Роздач

Зразок вразливості: 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

Контекст вразливості: Зловмисники можуть виконати атаку на відмову в обслуговуванні, відправивши кілька токенів на адресу винагороди ланцюга постачальника. У поточному струмені виконання EndBlocker ланцюга споживача функція SendRewardsToProvider, визначена в x/ccv/consumer/keeper/distribution.go, отримує баланс всіх токенів у tstProviderAddr та відправляє їх на ланцюг постачальника. Для цього потрібно пройтися по всіх токенах, знайдених у адресі винагороди, та відправити кожен через IBC на ланцюг постачальника. Оскільки будь-хто може відправити токени на адресу винагороди, зловмисники можуть створювати та відправляти велику кількість різних токенів, наприклад, використовуючи ланцюг з модулем фабрики токенів, для ініціювання атаки на відмову в обслуговуванні. Тому виконання EndBlocker займе більше часу та ресурсів, ніж очікувалося, сповільнюючи або навіть зупиняючи ланцюг споживача.

Місце вразливості: Посилання на GitHub з безпекою міжцепових космосів

Вразливий сегмент коду:

Тригер шляху вразливості:

AppModule.EndBlock

EndBlock

EndBlockRD

Надіслати винагороди постачальнику

Другий тип ситуації

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

Приклад 1

Уразливість: Космос SDK Security Advisory Jackfruit

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

Оголошення про вразливість:

• Посилання на форум Cosmos 1

• Посилання на форум Космосу 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 проекту: Sei Cosmos GitHub Repository

У кількох випадках у репозиторіях коду, пов'язаних з Cosmos, використовується тип даних map мови Go та ітерація по ньому. Через недетерміновану природу ітерації по map у мові Go це може призвести до досягнення вузлами різних станів, що потенційно може спричинити проблеми з консенсусом і, внаслідок цього, зупинити роботу ланцюжка. Більш відповідним методом буде відсортувати ключі map в масив та ітеруватися по відсортованих ключах. Такі проблеми є загальними і випливають з використання мовних можливостей.

При реалізації BuildDependencyDag в x/accesscontrol/keeper/keeper.go, існує ітерація над вузлами anteDepSet. Через недетерміновану поведінку ітерації по мапі в Go, ValidateAccessOp може призвести до двох різних типів помилок, що потенційно може призвести до відмови в консенсусі.

Місце вразливості: Sei Cosmos GitHub Кодовий відрізок

Вразливий сегмент коду:

З цих випадків очевидно, що уразливості, які призводять до зупинки ланцюга пасивно, часто є найшкідливішими. Їх причинна логіка може бути відстежена до безпосереднього впливу на виконавчий потік окремих блоків у блокчейні. На відміну, вразливості безпеки консенсусу зазвичай призводять до того, що ланцюг активно зупиняється для впровадження виправлень, причинна логіка яких відстежується до впливу на загальний операційний потік та стан блокчейну. Це відрізняється від уваги до уразливостей, які призводять до фінансових втрат, де конкретний небезпечний вплив не оцінюється на основі логічного шляху виникнення проблеми, а зосереджується на власниках коштів, сумі грошей, обсязі та методах, що впливають на кошти.

втрата коштів

Проблеми втрати капіталу часто спостерігаються в логічній обробці sdk.Msg та повідомлень IBC. Звичайно, також існують деякі уразливості, які можуть призвести до втрати капіталу серед причин, які можуть зупинити роботу блокчейну. Конкретний вплив залежить від конкретної уразливості, і тут ми зосереджуємося на першій. Крім того, оскільки IBC є дуже важливою складовою екосистеми Cosmos, це неминуче пов'язано з деякими уразливостями в IBC. Деталі про атаки на IBC та відповідні уразливості будуть обговорені у наступному розділі.

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

Тут ми візьмемо за приклад проєкт SuperNova для аналізу трьох пов'язаних вразливостей.

Зразок уразливості: Проект SuperNova

Посилання на проект: 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.ClaimSnAsset

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. Це призвело до пропуску перевірок важливих вбудованих змінних, що створює певні ризики безпеки.

Case Study: Cosmos SDK Security Advisory Барбарис

Контекст вразливості: MsgCreatePeriodicVestingAccount.ValidateBasic не має механізмів для оцінки статусу облікового запису, наприклад, чи він активний. У визначеному x/auth обліковому запису з періодичним відкладенням атакувальник може ініціювати обліковий запис жертви до зловмисного облікового запису. Цей обліковий запис дозволяє здійснювати внески, але забороняє виведення. Коли користувачі вносять кошти на свій обліковий запис, ці кошти будуть назавжди заблоковані, і користувач не зможе їх вивести.

Вразливість патч:

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 були також присутні в Космос-SDK Security Advisory Elderflower та Космос-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 та відповідні методи обробки Keeper. Тому багато проблем, пов'язаних з протоколом IBC, виникають у шляхах коду інтерфейсів IBCModule для отримання та обробки пакетів (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket і т. д.).

Загальні класифікації вразливостей

У космічній екосистемі протокол IBC виступає в якості з'єднувального хабу. Типи вразливостей, пов'язаних з протоколом IBC, різноманітні та складні через тісну інтеграцію його реалізацій з модулями, такими як Cosmos-SDK та CometBFT. Крім того, оскільки IBC використовується в основному в екосистемі Cosmos, його основна мова програмування - Golang, як детально описано в документації ibc-go.

Through the space constraints, this article does not delve into a detailed analysis of every aspect and component of the IBC protocol. Instead, it classifies some of the existing security vulnerabilities. For a more detailed and comprehensive analysis, you are welcome to contact our CertiK security engineers for discussion.

Загальні класифікації вразливостей:

1. Помилки в назвах

   ① Обробка рядків, уразливості

   ② Обробка уразливостей байткоду

2. Вразливості процесу передачі

   ① Вразливості замовлення пакетів

   ② Порушення тайм-ауту пакета

   ③ Вразливості аутентифікації пакетів

   ④ Інші вразливості пакетів

3. Логічні вразливості

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

   ② Голосування та Вразливості Консенсусу

   ③ Інші логічні вразливості

4. Вразливості споживання газу

Існуючий протокол IBC, щодо аудиту та аналізу його безпеки, має багато спільних рис з процесами аудиту протоколів Web2. Цей аналіз проаналізує деякі питання безпеки та потенційні ризики протоколу IBC з точки зору створення протоколу, його впровадження та розширення застосування. Оскільки формулювання протоколу часто завершується кількома особами та організаціями, для різних блокчейн-організацій більше роботи обертається навколо впровадження та розширення застосування протоколу. Тому ця стаття зосередиться на питаннях безпеки цих аспектів. Цей підхід випливає з розгляду широкого спектру ризиків безпеки, які охоплюються протоколом IBC, що дозволяє краще категоризувати різні типи питань безпеки на відповідні етапи та модулі.

Аналіз вразливостей

Формулювання протоколу IBC

Case Study 1: Протокол ICS-07, Логічна Вразливість

Зразок уразливості: Неправильне використання періоду розблокування

У коді існує наступна перевірка:

якщо 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 Protocol, Naming Vulnerability

Уразливість: Конфлікт адреси кастодіального сховища. GetEscrowAddress()функція генерує 20-байтовий скорочений SHA256 (ідентифікатор порту + ідентифікатор каналу). Цей метод має три проблеми:

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 використовуватиме структуру пакету при обробці пакетів даних додатків. Згідно з механізмом тайм-ауту, синхронним та асинхронним механізмами підтвердження та відповідним процесом перевірки сертифікатів, пакет даних буде розділено на два процеси виконання:

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: вразливість airdrop кроку, логічна вразливість

Контекст вразливості: Функція Спробуйте оновити претензію на роздачуконвертує адресу відправника пакета IBC в адресу Stride з назвоюадреса відправника крок, та вилучає ідентифікатор роздачіта нова адреса роздачіnewStrideAddressз метаданих пакета. Потім він викликаєОновитиAirdropAddressоновитиадреса відправникаStride та Заява про запис. З оновленням Запис вимоги, новаАдресаStrideзможе претендувати на роздачу токенів. Однак ця функція оновлення лише перевіряє, чи порожня адреса відправника запиту, та не перевіряєnewStrideAddressОскільки 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'. В результаті пошкоджені транзакції не можуть бути включені в блок ланцюжка блоків. Це невдача може призвести до того, що посередники IBC будуть намагатися повторно подати ці повідомлення. Такі повторні подання можуть призвести до фінансових втрат для посередників та перевантаження мережі чрез надмірну кількість необроблених ('залишених') пакетів, що становить ризик для стабільності мережі.

Адреса проекту: 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. Ці зростаючі побоювання передбачається, що стануть все більш значущими у майбутньому, особливо щодо загальної безпеки космосу. Ця зміна свідчить про зростаючий акцент на забезпечення надійних заходів безпеки в модулі IBC.

Висновок

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

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

Незважаючи на ці перешкоди, ми оптимістичні. Документуючи та аналізуючи загальні сценарії та виклики безпеки, як ми це зробили в цьому звіті, ми вкладаємо камінь у фундамент поступового покращення загальної структури безпеки в різноманітному екосистемі Cosmos.

Disclaimer:

1. Ця стаття переписана з [ CertiK]. Усі авторські права належать оригінальному автору [CertiK]. Якщо є заперечення проти цього повторного друку, будь ласка, зв'яжіться зGate Навчаннякоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими, що належать автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонені.