Хакерські мости

TL;DR Bridges відіграють дедалі важливішу роль, дозволяючи різним блокчейнам спілкуватися один з одним. Брати та засновники компанії Sayfer Нір Дуан (генеральний директор) та Ор Дуан (технічний директор) поділилися досвідом практичного хакерства та своїм новим лідерством у сфері аудиту web3 на Israel Crypto Community (ICC) 22 вересня/ 9 про те, чому мости настільки сприйнятливі до атак, як їх зламують і які найкращі підходи до успішного аудиту смарт-контрактів на мосту.

Чому міст потрібно перевіряти?

Мости є надзвичайно прибутковою мішенню для криптохакерів. Більше $ 1.6 млрд були вкрадені лише у 2022 році. Це в поєднанні з властивою складністю кодування мосту робить аудит невід’ємною частиною процесу розгортання. Sayfer допомагає іншим компаніям стати більш безпечними, виконуючи тести на проникнення, які є важливою частиною повного аудиту безпеки. Аудит смарт-контрактів — це спеціалізована частина аудиту безпеки, розроблена для коду сучасного web3, децентралізованого додатка або децентралізованого додатка, пов’язаного з блокчейном. Процес аудиту спрямований на те, щоб переконатися, що коли незмінний контракт розгорнуто в блокчейні, він може виконувати лише те, для чого призначений. Мости представляють ще більш спеціалізований випадок для аудиторів, оскільки вони містять компоненти коду в обох ланцюжках, а також компонент поза ланцюгом. Якщо правильно мислення безпеки і аудит не буде реалізовано в цій сфері розробки web3, дуже ймовірно, що мільйони доларів у токенах продовжуватимуть вичерпуватись із погано спроектованих мостів.

Покроковий посібник з аудиту мосту

Дізнайтеся про архітектуру

Природно, для аудиту потрібно звернути увагу на хакерське мислення «білого капелюха» щодо пошуку вразливостей і способів атакувати контракт так само, як це зробив би хакер «чорного капелюха». Найважливіша частина, перш ніж вирішити, як підійти до атаки на міст, це зрозуміти його модель безпеки. У найзагальнішому розумінні мости можуть бути Довіренийабо недовірливий. Модель довіри, або централізована bridge, спирається на один керівний компонент, який в кінцевому підсумку може вирішити, скільки грошей переміщується з одного ланцюжка до іншого. У безнадійному або Децентралізований bridge, існує окремий механізм консенсусу, який перевіряє кожен запит на переказ грошей між ланцюжками. Ця частина надзвичайно важлива, коли ми вирішуємо, як ми збираємося зламати або, для наших цілей, перевіряти цей міст. Хоча централізований міст може вважатися недостойним для багатьох у криптоспільноті через його залежність від єдиної сутності, ускладнення безпеки, пов’язані з підтримкою цілого окремого механізму консенсусу, не залишають безнадійні мости без власних застережень.

Керування ключами

Хто контролює ключі? Бо якщо це небезпечно, нічого не безпечно, як ми бачили з Ронін рубати. Навіть якщо консенсус розподіляється між кількома різними організаціями, ми маємо розглянути, наскільки легко було б взяти на себе контроль і наскільки далеко хтось готовий би зайти для цього.

Архітектура валідатора

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

Розуміння кодової бази

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

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

Далі перегляньте тести, надані розробниками. Вони можуть допомогти вам краще зрозуміти базу коду, а також пізніше спробувати власне тестування експлойтів і вразливостей. Вам не потрібно винаходити колесо! Якщо у вас є тести з налаштуваннями та розривами, ви можете просто скопіювати тест, змінити його та створити свій власний.

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

Інструменти аудиту

Побудова графіка a графік виклику функції може бути великою підмогою в розумінні структури контрактів і функцій у них. сурйа від ConsenSys пропонує цю функцію.

Інструменти, які пропонують диференційний аналіз, також дуже корисні для аудиту контрактів, виходячи з того, що багато з найпопулярніших і надійних блокчейн-проектів базують свій код на основі інших проектів з відкритим кодом. Якщо основна база коду, яку кілька разів перевіряли лідери галузі, використовується в іншому проекті, хоча це не означає, що її неможливо зламати, ми можемо вважати, що вона відносно безпечна, і зосередити наші зусилля на перевірці на частинах коду, які насправді змінилися між двома проектами. Все частіше Сейфер бачить клієнтів, де вони знаходять серйозні вразливості лише в diff. Ось чому вони розробили власний інструмент під назвою smartdiffer, який порівнює вихідний код смарт-контрактів і спирається на API Etherscan і Diffchecker.

Автоматизовані сканери — наші друзі як аудитори для пошуку «низько висять плодів». Найбільш часто використовуваним засобом є сліз. Або наголошує на важливості підходу до запуску сканера вразливостей: не просто запускайте інструмент і не сподівайтесь на відсутність червоних попереджень. Ставтеся до нього саме як до інструменту. Щоб зменшити шум від результату, використовуйте прапорці, щоб виключити певні шляхи, залежності чи детектори зі сканування. Ви також можете використовувати параметр виводу у форматі .json, що спрощує потім фільтрування та створення певного списку справ для вашого аудиту.

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

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

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

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

Підсумки

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