Які поширені безпечні вразливості міжланцюгового мосту?

Резюме

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

Вступ

Мости блокчейну — це протоколи, що з’єднують два блокчейни, дозволяючи їм взаємодіяти. За допомогою мостів користувачі, щоб брати участь у DeFi-активностях мережі Ethereum, можуть просто володіти Bitcoin, не продаючи його.

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

Чому безпека мостів блокчейну так важлива?

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

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

За оцінками CertiK, у 2022 році атаки на мости блокчейну спричинили збитки понад 1,3 мільярда доларів, що становить 36% від загальних збитків за рік.

Поширені вразливості безпеки міжланцюгових мостів

Щоб підвищити безпеку мостів блокчейну, важливо знати про поширені вразливості та тестувати їх перед запуском. Ці вразливості в основному виникають через чотири основні аспекти:

Недостатня валідація на ланцюгу

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

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

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

Деякі мости застосовують концепцію “обгортання токенів(wrapped tokens)”. Наприклад, коли користувач переносить DAI з Ethereum до BNB Chain, його DAI знімаються з контракту Ethereum і на BNB Chain випускається еквівалентна обгортка DAI.

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

Зловмисник також повинен отримати попереднє схвалення користувача для контракту мосту, щоб використовувати функцію “TransferFrom” і вивести активи з мосту.

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

Недостатня поза ланцюгова валідація

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

Принцип роботи мостів із поза ланцюговою валідацією такий:

Користувач взаємодіє з dApp, вносить токени у смарт-контракт на вихідному ланцюгу.

Потім dApp через API надсилає хеш транзакції поповнення на бекенд-сервер.

Хеш транзакції має пройти кілька перевірок на сервері. Якщо транзакція вважається легітимною, підписувач підписує повідомлення і повертає підпис через API у інтерфейс користувача.

Після отримання підпису, dApp перевіряє його і дозволяє користувачу зняти токени з цільового ланцюга.

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

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

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

Некоректне оброблення нативних токенів

Мости міжланцюгові застосовують різні підходи до обробки нативних та утилітарних токенів. Наприклад, у мережі Ethereum нативним токеном є ETH, а більшість утилітарних токенів відповідають стандарту ERC-20.

Якщо користувач планує перенести свої ETH на інший ланцюг, він має спершу внести їх у смарт-контракт моста. Для цього достатньо додати ETH до транзакції, використовуючи поле “msg.value” для визначення кількості ETH.

Внесення ERC-20 токенів суттєво відрізняється від внесення ETH. Щоб внести ERC-20 токени, користувач має спершу дозволити смарт-контракту моста використовувати їх. Після схвалення і внесення токенів у контракт, він може знищити їх за допомогою функції “burnFrom(” або перевести їх на контракт за допомогою “transferFrom)”.

Щоб розрізняти ці операції, можна використовувати умовні оператори if-else у одному функціоналі або створити два окремі функції для кожного сценарію. Оскільки обробка різна, спроба використати функцію для ERC-20 для внесення ETH може призвести до втрати коштів.

При обробці запитів на внесення ERC-20 користувач зазвичай передає адресу токена як вхідний параметр. Це створює значний ризик, оскільки під час транзакції можливі зовнішні виклики, які не можна довіряти. Використання білого списку підтримуваних мостом токенів — поширена практика для мінімізації ризиків. Тільки адреси, що внесені до білого списку, передаються як параметри. Це запобігає зовнішнім викликам, оскільки команда проекту вже відфільтрувала адреси токенів.

Однак, при обробці нативних токенів, що передаються через міжланцюговий міст, виникає проблема — нативні токени не мають адреси. Вони можуть використовувати спеціальну адресу, наприклад “нульову адресу”(0x000…). Але це створює ризик: якщо логіка білого списку неправильно реалізована, передача через нульову адресу може обійти перевірку.

Коли контракт моста викликає “TransferFrom” для переказу активів користувача на контракт, зовнішній виклик нульової адреси поверне false, оскільки у нульової адреси не реалізовано функцію “transferFrom”. Однак, якщо контракт неправильно обробляє повертаємі значення, транзакція може все одно пройти. Це створює можливість для зловмисника виконати транзакцію без фактичного переказу токенів.

Помилки у конфігурації

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

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

Як підвищити безпеку міжланцюгових мостів

Вищезазначені чотири поширені вразливості мостів показують, що безпека у взаємопов’язаній блокчейн-екосистемі є серйозним викликом. Щоб протистояти цим вразливостям, потрібно застосовувати “індивідуальний підхід”, оскільки жоден універсальний метод не може одночасно усунути всі проблеми.

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

Загалом, потрібно ретельно тестувати потенційні атаки і особливо звертати увагу на найпоширеніші вразливості у безпеці мостів.

Заключення

Через значні обсяги коштів мости міжланцюгові довгий час залишаються ціллю для зловмисників. Розробники можуть підвищити безпеку мостів, проводячи всебічне тестування перед розгортанням і залучаючи сторонні аудити, що зменшить ризик катастрофічних хакерських атак, які траплялися за останні роки. Мости міжланцюгові є критично важливими у багатоланцюговому світі, але при проектуванні та створенні ефективної інфраструктури Web3 безпека має бути пріоритетом. ($STO