Посібник з безпеки DeFi: як ефективно захищатися від хакерських атак у епоху штучного інтелекту?

Оригінальна назва: Як зупинити втрату грошей через DeFi-хакі
Автор оригіналу: sysls, openforage
Переклад оригіналу: AididiaoJP, Foresight News

Вступ

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

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

Я щиро вірю, що виживають лише ті, хто навчився бути навіженим. Жодна команда не починає з думки «Я буду ставитися до безпеки байдуже і поверхнево»; однак атаки все одно трапляються. Нам потрібно робити краще.

Штучний інтелект означає, що цього разу все справді інакше

(Джерело даних: https://defillama.com/hacks)

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

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

Це має кардинально змінити наш підхід до аналізу та протидії хакерським атакам. Старі протоколи, які звикли покладатися на безпеку до того, як AI став потужним, тепер все більше ризикують бути «змазаними» за секунду.

Мислення поверхнями та рівнями

(Джерело даних: https://defillama.com/hacks)

Площа поверхні для хакерських атак фактично можна звести до трьох: команда протоколу, смарт-контракти та інфраструктура, межі довіри користувачів (DSN, соціальні мережі тощо).

Якщо визначили ці поверхні — додайте рівні захисту:

· Запобігання: якщо строго дотримуватися, можна максимально знизити ймовірність експлуатації.

· Пом’якшення: у разі провалу запобігання — обмежити масштаби шкоди.

· Пауза: ніхто не може приймати найкращі рішення під великим тиском. Після підтвердження атаки — негайно активуйте «загальний аварійний режим». Замороження може запобігти подальшим втратам і дати час подумати…

· Відновлення: якщо ви втратили контроль над токсичними або зламаними компонентами — відмовтеся від них і замініть.

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

Принципи

Ці принципи керують конкретними діями для реалізації багаторівневого захисту.

Активне використання передового AI

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

Використовуйте навички pashov, nemesis та платформи AI, такі як Cantina (Apex) і Zellic (V12), для швидкого сканування коду перед повним аудитом.

Час і тертя — це хороші захисні засоби

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

Раніше аргументом проти тайм-локів і багатоступеневих налаштувань була їхня «тертя» для команд протоколу. Тепер вам не потрібно так сильно хвилюватися: AI легко може пройти ці перешкоди у фоновому режимі.

Неперервні змінні

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

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

Баланс влади

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

Це вимагає балансу між управлінням (прийняттям рішень) і рятувальними заходами (відновленням стабільності, але без можливості скасувати або змінити управління).

Завжди можливі проблеми

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

Якщо так думати — обмежуйте шкоду швидко, використовуючи тайм-ліміти і аварійні перемикачі. Обмежте шкоду до 5-10%, потім заморожуйте і плануйте дії. Ніхто не може прийняти найкраще рішення під кулеметним вогнем.

Найкращий час для планування — зараз

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

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

Відсутність ознак зламу не означає, що вас не зломають. Найбільша небезпека — це найзручніша точка.

Заходи профілактики

Дизайн смарт-контрактів

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

Це і є модель FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants): наприкінці кожної функції, що має цінність, повторно перевіряйте обіцяні незмінні «корони». Багато атак, що базуються на CEI (Checks-Effects-Interactions) (швидкі позики, ліквідація через оракули, витягнення коштів між функціями) можна виявити саме цими перевірками.

Грунтовне тестування

Статичне fuzz-тестування (Stateful fuzzing) генерує випадкові послідовності викликів для протоколу і перевіряє не змінні на кожному кроці. Більшість вразливостей у виробничих системах — багатокрокові, і саме статичне fuzz-тестування є найнадійнішим способом виявити їх до атакуючих.

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

Оракули та залежності

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

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

Останній приклад — вразливість KelpDAO: вони використовували стандартну конфігурацію LayerZero requiredDVNCount=1, яка не входила до їхнього аудиту. В результаті зламали зовнішню інфраструктуру поза межами аудиту.

Поверхневі атаки

Більшість поверхневих атак у DeFi вже перераховані. Перевірте кожен тип, запитайте себе, чи застосовний він до вашого протоколу, і впровадьте контроль для кожного вектора. Розвивайте навички червоних команд, щоб ваш AI-інтелект самостійно шукав уразливості — це вже стандартна практика.

Мати вбудовану здатність до порятунку

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

Розгорніть «гаманці-охоронці», з обмеженими правами: вони можуть лише призупинити протокол і, при >=4/7 голосів, у крайніх випадках — замінити пошкоджені гаманці на заздалегідь визначені. Охоронці не можуть ініціювати управлінські пропозиції.

Таким чином, у вас буде резервний рівень для відновлення управління, без можливості скасувати або змінити управління. Ймовірність втрати >=4/7 охоронців — дуже низька (з урахуванням різноманітності власників), і з часом, коли управління стане більш розподіленим — цей рівень можна буде поступово зняти.

Гаманці та топологія ключів

Мульти-підпис — мінімальна вимога, не менше 4/7. Ніколи не контролюйте всі 7 ключів одним особисто. Регулярно змінюйте підписантів і робіть це непомітно.

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

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

Розгляньте винагороду

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

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

Знаходьте хороших аудиторів

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

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

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

Практика операційної безпеки

Розглядайте операційну безпеку як ключовий показник успіху. Проводьте тренінги з фішингу; наймайте (надійних) червоних команд для соціотехнічних атак. Майте запасні апарати для гаманців і пристроїв, щоб у разі потреби швидко замінити мульти-підпис. Не готуйтеся в останню хвилину.

Заходи пом’якшення

Ваш шлях виходу — це обмеження збитків

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

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

Білі та чорні списки

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

Формалізація дозволяє створити двоступеневі налаштування, що створюють додаткові перешкоди. Атакуючий спершу має додати себе до білого списку (або видалити з чорного), щоб діяти. Мати обидва — означає, що для додавання нових векторів атаки потрібно одночасно зламати два процеси: дозволити їх (інтеграція/виведення на ринок) і не заборонити (перевірка безпеки).

Відновлення

Моніторинг алгоритмів

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

Зупинитись і переналаштувати

Якщо вас зломали — спершу зупиніться і зупиніть кровотечу, а не намагайтеся ухвалювати рішення у поспіху. Для протоколу це — аварійний перемикач (також відображений у UI): кнопка, що миттєво зупиняє всі рухи цінностей. Підготуйте скрипт для «пауза всього», що перераховує всі компоненти, які можна призупинити, і виконує їх одночасно.

Лише управління може зняти паузу — аварійний перемикач не може зупинити сам управлінський контракт. Якщо охоронці можуть зупинити управління — злом охоронців призведе до безвихідної блокування процесу відновлення.

Запустіть командний центр

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

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

Коли всі знають свої ролі і тренуються — ви зможете діяти за планом, а не в паніці.

Розгляньте ланцюгову реакцію

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

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

Заздалегідь визначайте наступників

Лише заздалегідь узгоджені наступники забезпечують безпечну ротацію. Мені подобається ідея реєстру попередніх наступників: вона ускладнює зловмиснику підміну здорових охоронців або управлінських гаманців на зламані. Це відповідає концепції «білих» і «чорних» списків у заходах пом’якшення.

Зареєструйте для кожної важливої ролі свого наступника. Єдина команда, яка може виконати екстрену ротацію — це «замінити роль X на її наступника». Це дозволяє у спокійній обстановці оцінити кандидатуру, провести дью-дилидженс і зустрітися з претендентом.

Перед оновленням — ретельно тестуйте

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

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

Відновлення

Швидке реагування

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

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

Переговори

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

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

Перед цим обов’язково залучайте юридичних консультантів.

Висновки

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

Посилання на оригінал

Дізнайтеся більше про вакансії в BlockBeats

Запрошуємо приєднатися до офіційної спільноти BlockBeats:

Telegram-канал: https://t.me/theblockbeats

Telegram-група: https://t.me/BlockBeats_App

Офіційний Twitter: https://twitter.com/BlockBeatsAsia