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

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

Автор оригіналу: BlockBeats

Джерело оригіналу:

Репост: Mars Finance

Вступ

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

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

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

AI означає, що цього разу все справді інакше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Відновлення

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

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

Зупинка і переналаштування

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

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

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

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

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

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

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

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

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

Попередня заміна запланованих наступників

Заміна має бути заздалегідь відомою. Це — безпечний спосіб, щоб уникнути підміни здорових охоронців або управлінських гаманців на зламані. Ідея полягає у створенні реєстру попередніх наступників: це ускладнює зловмиснику підміну.

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

Обережне тестування перед оновленням

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

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

Відновлення

Швидкі дії

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

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

Переговори

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

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

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

Висновки

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