Посібник з безпеки 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, яка не входила до їхнього аудиту. В результаті зламали зовнішню інфраструктуру, що знаходилася поза межами аудиту.

Surface attacks

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

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

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

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

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

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

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

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

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

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

Якщо маєте ресурси, встановіть високий бонус за виявлення вразливостей, пропорційний TVL протоколу; навіть для невеликих протоколів — щедрий бонус (мінімум 7-8 цифр).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Відновлення контролю

Алгоритмічний моніторинг

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

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

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

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

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

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

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

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

Розглядайте ланцюгові реакції

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

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

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

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

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

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

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

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

Відновлення

Швидкі дії

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

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

Переговори

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

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

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

Висновки

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

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

Дізнайтеся про вакансії в BlockBeats на їхньому сайті

Приєднуйтесь до офіційної спільноти BlockBeats:

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

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

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