Ця стаття створена спільнотою. Автор – Minzhi He, аудитор – CertiK.
Думки у цій статті належать учаснику/автору і не обовʼязково відображають думку Binance Academy.
Короткий зміст
Блокчейн-мости мають вирішальне значення для досягнення функціональної сумісності у блокчейн-просторі. Отже, безпека мостів має першорядне значення. Деякі поширені вразливості безпеки мостів включають слабку ончейн та офчейн перевірку, неправильну обробку нативних токенів та неправильні конфігурації. Рекомендується протестувати міст проти всіх можливих векторів атаки, щоб забезпечити надійну логіку перевірки.
Вступ
Блокчейн-міст – це протокол, що зʼєднує два блокчейни для забезпечення взаємодії між ними. Якщо ви володієте Bitcoin, але хочете брати участь у DeFi-активності в мережі Ethereum, блокчейн-міст дозволить вам зробити це, не продаючи ваші Bitcoin.
Блокчейн-мости мають фундаментальне значення для досягнення функціональної сумісності у блокчейн-просторі. Вони функціонують з використанням різних ончейн та офчейн перевірок і, відповідно, мають різні вразливості безпеки.
Чому безпека моста важлива?
Міст зазвичай містить токен, який користувач хоче переказати з одного блокчейну до іншого. Часто розгорнуті як смартконтракти, мости зберігають значну кількість токенів, особливо за умови накопичення кросчейн переказів, що робить їх прибутковими цілями для хакерів.
Крім того, блокчейн-мости мають велику область для атаки, оскільки вони включають безліч компонентів. Маючи це на увазі, зловмисники дуже зацікавлені у зломі кросчейн застосунків та крадіжці великих сум коштів.
За оцінками CertiK, атаки на мости призвели до збитків у розмірі понад 1,3 млрд. доларів США в 2022 році, що становить 36% від загального обсягу збитків за рік.
Поширені вразливості безпеки моста
Щоб підвищити рівень безпеки мостів, важливо розуміти поширені вразливості їхньої безпеки та тестувати мости на їх наявність перед запуском. Ці вразливості можна розділити на чотири області.
Слабка ончейн перевірка
Для простих мостів, особливо розроблених для конкретних dApp, ончейн перевірка зведена до мінімуму. Ці мости покладаються на централізований внутрішній сервер для виконання основних операцій, таких як створення, спалювання та переказ токенів, у той час як усі перевірки виконуються офчейн.
І навпаки, інші типи мостів використовують смартконтракти для перевірки повідомлень та виконання перевірок ончейн. У цьому сценарії, коли користувач депонує кошти у блокчейн, смартконтракт генерує підписане повідомлення та повертає підпис у транзакції. Цей підпис є доказом депозиту та використовується для перевірки запиту користувача на зняття в іншому блокчейні. Цей процес повинен запобігати різноманітним атакам на систему безпеки, у тому числі атакам з повторним відтворенням та підробленим депозитними записами.
Однак, якщо в процесі ончейн перевірки виникає вразливість, зловмисник може завдати серйозної шкоди. Наприклад, якщо міст використовує дерево Меркла для перевірки запису транзакції, зловмисник може згенерувати підроблені докази. Це означає, що він може обійти перевірку підтвердження та викарбувати нові токени для свого акаунту, якщо процес перевірки вразливий.
Деякі мости реалізують концепцію "wrapped токенів". Наприклад, коли користувач переказує DAI з Ethereum на BNB Chain, його DAI беруться з контракту Ethereum, і у BNB Chain випускається еквівалентна кількість wrapped DAI.
Однак, якщо ця транзакція не перевірена належним чином, зловмисник може розгорнути зловмисний контракт для маршрутизації wrapped токенів з моста на неправильну адресу, маніпулюючи функцією.
Зловмисникам також потрібно, щоб жертви схвалили контракт моста для переказу токенів за допомогою функції "transferFrom" для зливу активів з контракту моста.
На жаль, ситуація посилюється тим, що багато мостів створюють запити на необмежену кількість токенів від користувачів dApp. Це звичайна практика, яка знижує комісію gas, але створює додаткові ризики, що дозволяє смартконтракту отримувати доступ до необмеженої кількості токенів з гаманця користувача. Зловмисники можуть використовувати відсутність перевірки та надмірне схвалення для переказу токенів від інших користувачів собі.
Слабка офчейн перевірка
У деяких системах моста, внутрішній офчейн сервер відіграє вирішальну роль у перевірці легітимності повідомлень, надісланих із блокчейну. У цьому випадку ми зосереджені на перевірці депозитних транзакцій.
Блокчейн-міст з офчейн перевіркою працює наступним чином:
Користувачі взаємодіють із dApp для депозиту токенів у смартконтракт у вихідному блокчейні.
Потім dApp надсилає хеш транзакції депозиту на внутрішній сервер через API.
Хеш транзакції проходить декілька перевірок сервером. Якщо хеш вважається законним, підписант підписує повідомлення і надсилає підпис назад в інтерфейс користувача через API.
Отримавши підпис, dApp перевіряє його і дозволяє користувачеві зняти свої токени з цільового блокчейну.
Внутрішній сервер повинен переконатися, що транзакція депозиту, яку він обробляє, справді відбулася і не була підроблена. Цей внутрішній сервер визначає, чи користувач може знімати токени з цільового блокчейну, і тому є важливою ціллю для зловмисників.
Внутрішній сервер повинен перевірити структуру події, згенерованої транзакцією, а також адресу контракту, який згенерував подію. Якщо знехтувати останнім, зловмисник може розгорнути зловмисний контракт для підробки події депозиту з тією самою структурою, що й законна подія депозиту.
Якщо внутрішній сервер не перевірить, яка адреса згенерувала подію, він вважатиме це дійсною транзакцією і підпише повідомлення. Потім зловмисник може надіслати хеш транзакції на внутрішній сервер, минаючи перевірку та дозволивши зняти токени з цільового блокчейну.
Неправильне поводження з нативними токенами
Мости використовують різні підходи до обробки нативних токенів та утиліті токенів. Наприклад, у мережі Ethereum нативним токеном є ETH, і більшість утиліті токенів відповідають стандарту ERC-20.
Коли користувач має намір переказати свої ETH в інший ланцюг, він повинен спочатку депонувати їх до контракту моста. Для цього користувач просто прикріплює ETH до транзакції, а кількість ETH можна отримати, прочитавши поле транзакції "msg.value".
Депозит токенів ERC-20 значно відрізняється від депозиту ETH. Щоб депонувати токен ERC-20, користувач повинен спочатку дозволити контракту моста витратити свої токени. Після схвалення і переміщення токенів у контракт моста, контракт або спалить токени користувача за допомогою функції "burnFrom()", або перекаже токени користувача у контракт за допомогою функції "transferFrom()".
Одним із підходів до диференціації є використання оператора "if-else" у тій самій функції. Інший підхід полягає у створенні двох окремих функцій для обробки кожного сценарію. Спроба депонувати ETH за допомогою функції депозиту ERC-20 може призвести до втрати цих коштів.
Під час обробки запитів на ERC-20 депозит, користувачі зазвичай надають адресу токена як входи для функції депозиту. Це складає значний ризик, оскільки під час транзакції можуть відбуватися ненадійні зовнішні виклики. Реалізація білого списку, що включає лише токени, які підтримуються мостом, є звичайною практикою для мінімізації ризиків. Лише адреси з білого списку можна передавати як аргументи. Це запобігає зовнішнім викликам, оскільки команда проєкту вже відфільтрувала адресу токена.
Проте, проблеми можуть також виникнути, коли мости обробляють кросчейн переказ нативних токенів, оскільки нативний токен не має адреси. Нативний токен представляє нульова адреса (0x000...0). Це може бути проблематично, оскільки передача нульової адреси до функції може обійти перевірку білого списку, навіть якщо вона реалізована правильно.
Коли контракт моста викликає "transferFrom" для переказу активів користувача до контракту, зовнішній виклик до нульової адреси повертає "false", оскільки в нульовій адресі не реалізована функція "transferFrom". Однак транзакція все одно може відбутися, якщо контракт не обробляє значення, що повертається належним чином. Це дає зловмисникам можливість виконати транзакцію без переказу будь-яких токенів у контракт.
Неправильна конфігурація
У більшості блокчейн-мостів, привілейована роль відповідає за внесення до білого або чорного списків токенів та адрес, призначення або зміну підписантів та інші важливі налаштування. Забезпечення точності всіх змін має вирішальне значення, оскільки навіть, здавалося б, дрібʼязкові недогляди можуть призвести до значних втрат.
Насправді стався інцидент, коли зловмисник успішно обійшов перевірку запису переказу через неправильну конфігурацію. Команда проєкту реалізувала оновлення протоколу за кілька днів до злому, яке включало зміну змінної. Ця змінна використовувалась для надання значення за замовчуванням довіреного повідомлення. Ця зміна призвела до того, що всі повідомлення автоматично вважалися перевіреними, що дозволило зловмиснику надіслати довільне повідомлення та пройти процес перевірки.
Як покращити безпеку моста
Описані вище чотири поширені вразливості моста демонструють проблеми із гарантуванням безпеки у взаємопов’язаній екосистемі блокчейну. Існують важливі міркування щодо усунення кожної з цих уразливостей, і жодна з них не підходить для всіх.
Наприклад, надання загальних рекомендацій щодо забезпечення безпомилкового процесу перевірки є складним завданням, оскільки кожен міст має унікальні вимоги до перевірки. Найбільш ефективний підхід до запобігання обходу перевірки, полягає в тому, щоб ретельно перевірити міст на всі можливі вектори атак і переконатися, що логіка перевірки працює правильно.
Підводячи підсумок, важливо провести ретельне тестування щодо потенційних атак і приділити особливу увагу найбільш поширеним уразливостям безпеки мостів.
Підсумки
Через свою високу цінність, кросчейн мости вже давно є мішенню для зловмисників. Розробники можуть посилити безпеку своїх мостів, провівши ретельне тестування перед розгортанням та беручи участь у сторонніх аудитах, що знизить ризик руйнівних зламів, які переслідували мости протягом останніх кількох років. Мости мають вирішальне значення у мультичейн світі, але безпека має бути головним завданням під час проектування та створення ефективної інфраструктури Web3.
Пов'язані статті
Три популярні криптомости та як вони працюють
Відмова від відповідальності та попередження про ризики: цей контент надається вам на умовах "як є" тільки для загальної інформації та освітніх цілей, без будь-яких заяв чи гарантій. Його не слід розглядати як фінансову, юридичну чи іншу професійну пораду, і він не призначений для рекомендації купівлі будь-якого конкретного продукту чи послуги. Вам слід звернутися за порадою до відповідних професійних консультантів. Якщо стаття написана стороннім автором, зверніть увагу, що висловлені думки належать сторонньому автору, і не обов'язково відображають думку Binance Academy. Для отримання додаткової інформації, будь ласка, перегляньте нашу повну відмову від відповідальності. Ціни на цифрові активи можуть бути волатильними. Вартість ваших інвестицій може як впасти, так і зрости, і ви можете не повернути інвестовану суму. Ви несете повну відповідальність за свої інвестиційні рішення, і Binance Academy не несе відповідальності за збитки, які ви можете понести. Цей матеріал не повинен розглядатись як фінансова, юридична чи інша професійна порада. Для отримання додаткової інформації, будь ласка, перегляньте наші Умови користування та Попередження про ризик.