Руководство по безопасности DeFi: как эффективно защищаться от хакерских атак в эпоху ИИ?

Статья: sysls

Компиляция: AididiaoJP, Foresight News

Оригинальная ссылка:

Заявление: Эта статья является переработанным материалом, читатели могут получить дополнительную информацию по исходной ссылке. Если авторы возражают против формы переработки, пожалуйста, свяжитесь с нами, и мы внесем необходимые изменения. Перепечатка предназначена только для обмена информацией, она не является инвестиционной рекомендацией и не отражает точку зрения и позицию Wu.

Введение

Изучая множество случаев хакерских атак на DeFi-протоколы, у меня возникло ощущение страха перед «государственными субъектами». Они обладают высокой технической подготовкой, достаточными ресурсами и играют в очень долгосрочную игру; эти суперзлодеи сосредоточены на тщательном анализе каждого уголка ваших протоколов и инфраструктуры в поисках уязвимостей, в то время как обычные команды протоколов отвлечены на шесть-семь различных бизнес-направлений.

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

Я искренне верю, что выживают только одержимые. Ни одна команда изначально не думает: «Я буду относиться к безопасности легкомысленно и халатно»; однако атаки всё равно происходят. Нам нужно делать лучше.

Искусственный интеллект означает, что ситуация действительно изменилась

(Источник данных:

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

Мое основное предположение: ИИ значительно снизил стоимость поиска уязвимостей и расширил поверхность атаки. Человеку требуется несколько недель, чтобы просмотреть конфигурации сотни протоколов и найти ошибочные настройки; а современные базовые модели могут сделать это за несколько часов.

Это должно кардинально изменить наш подход к анализу и противодействию хакерским атакам. Старые протоколы, привыкшие к безопасности до появления мощных ИИ, все больше рискуют быть «моментально уничтоженными».

Использование поверхностного и иерархического мышления

(Источник данных:

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

Определив эти поверхности, можно наслоить защитные слои:

Профилактика: строгое выполнение процедур, максимально снижающих вероятность эксплуатации.

Смягчение: при неудаче профилактики — ограничение масштаба ущерба.

Пауза: никто не способен принимать оптимальные решения под сильным давлением. После обнаружения атаки — немедленно активировать общий аварийный выключатель. Заморозка может остановить дальнейшие потери и дать время на размышления…

Возврат: если контроль над вредоносными или взломанными компонентами утрачен — выбросить их и заменить.

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

Принципы

Эти принципы руководят конкретными действиями по реализации многоуровневой защиты.

Массовое использование передового ИИ

Массовое использование современных моделей ИИ для сканирования вашего кода и конфигураций, поиска уязвимостей и проведения красных командных тестов: попытки найти уязвимости на фронтенде, чтобы проверить, могут ли они достичь бэкенда. Атакающие делают так. То, что можно обнаружить с помощью защитных сканеров, они уже нашли с помощью атакующих.

Используйте навыки pashov, nemesis и платформы ИИ, такие как Cantina (Apex) и Zellic (V12), для быстрого сканирования кода до полного аудита.

Время и трение — хорошая защита

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

Раньше противились таймлокам и многоступенчатым настройкам, опасаясь трений для команды протокола. Сейчас это не так важно: ИИ легко может пройти эти трения в фоновом режиме.

Неподвижные свойства

Смарт-контракты могут строиться на основе написания неизменяемых «фактов»: если эти факты нарушаются, вся логика протокола рушится.

Обычно у вас есть лишь несколько таких неподвижных свойств. Их нужно аккуратно выводить на уровень кода; принудительное выполнение нескольких неподвижных свойств в каждом функции становится трудно управляемым.

Баланс власти

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

Это требует баланса между управлением (принимает все решения) и спасением (восстановление управляемой стабильности, но без возможности отмены или переворота управления).

Всегда возникают проблемы

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

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

Лучшее время для планирования — сейчас

Думайте о своих мерах защиты еще до взлома. По возможности автоматизируйте процессы и тренируйте команду, чтобы не паниковать при атаке. В эпоху ИИ это означает владение навыками и алгоритмами, способными максимально быстро предоставлять большие объемы информации, и делиться ими в кратком и расширенном виде с вашей командой.

Вам не нужен идеальный план, важно — выжить. Ни одна система с первого дня не является непобедимой; через итерации и обучение вы станете более устойчивыми.

Отсутствие признаков взлома не означает, что вас не взломают. Максимальная комфортность — это зачастую максимальная опасность.

Меры профилактики

Проектирование смарт-контрактов

После определения неподвижных свойств — выводите их в проверку во время выполнения. Вдумайтесь, какие из них действительно стоит принудительно соблюдать.

Это — модель FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants): в конце каждой функции, затрагивающей ценность, повторно проверяйте те неподвижные свойства, которые эта функция обязана сохранять. Многие атаки, основанные на CEI (Checks-Effects-Interactions) (например, флеш-лоаны, предсказания о ликвидации с помощью оракулов, межфункциональные выплаты), можно перехватить проверками неподвижных свойств в конце функции.

Хорошее тестирование

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

Используйте тесты на неподвижные свойства для проверки, что свойства выполняются во всех возможных последовательностях вызовов, которые генерирует мутационный тестер. В сочетании с формальной верификацией это доказывает, что свойства выполняются во всех достижимых состояниях. Ваши неподвижные свойства должны проходить такую проверку.

Оракулы и зависимости

Сложность — враг безопасности. Каждый внешний компонент расширяет поверхность атаки. При проектировании исходных элементов доверяйте только тем, кому действительно доверяете. Если зависимость не убрать — диверсифицируйте ее, чтобы ни одна точка отказа не могла разрушить протокол.

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

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

Поверхностные атаки

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

Обладание встроенными средствами спасения

В управлении на основе голосования власть изначально сосредоточена в мультиподписях команды, и требуется время для распространения. Даже при широком распределении токенов, делегирование зачастую концентрирует власть в нескольких кошельках (иногда даже в одном). В случае взлома этих кошельков игра окончена.

Разверните «стражевые кошельки», с жесткими ограничениями по полномочиям: они могут только приостанавливать протокол, а при наличии >=4/7 голосов — в экстремальных случаях заменять поврежденные делегированные кошельки на заранее подготовленные. Стражи никогда не могут инициировать управленческие предложения.

Так вы получите слой спасения, который всегда сможет вернуть протокол в управляемое состояние, не обладая полномочиями отменять управление. Вероятность того, что >=4/7 стражей будут взломаны, очень мала (учитывая диверсификацию владельцев), и по мере зрелости и децентрализации протокола этот слой можно постепенно выводить из эксплуатации.

Кошельки и топология ключей

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

Ключи никогда не должны взаимодействовать с повседневными устройствами. Если вы используете устройство для подписания, просматривая интернет, почту или Slack — значит, этот подписант уже взломан.

Используйте несколько мультиподписей, каждый для своей задачи. Предположите, что хотя бы один из них будет взломан, и планируйте исходя из этого. Ни один человек не должен иметь достаточной власти, чтобы взломать протокол, даже в экстремальных ситуациях (похищение, пытки и т.п.).

Обдумайте систему вознаграждений

Если есть ресурсы — установите высокую награду за обнаружение уязвимостей, особенно для небольших протоколов (минимум 7-8 цифр). Даже для небольшого протокола это стоит того.

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

Поиск хороших аудиторов

Я писал ранее, что по мере развития больших языковых моделей ценность найма аудиторов снижается. В этом есть доля правды, но мое мнение изменилось.

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

Во-вторых, недооцененная польза — это то, что нанимая аудиторов, вы пользуетесь их репутацией как гарантией. Если они одобрят и подпишут, а вас взломают — они будут сильно мотивированы помочь. Установление связей с профессионалами в области безопасности — огромное преимущество.

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

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

Меры смягчения

Ваш путь выхода — это лимит потерь

Любой путь вывода стоимости из протокола должен иметь ограничение по размеру. Это максимально возможный ущерб при использовании этого пути. Например, функция эмиссии без лимита — это пустой чек для любого неограниченного выпуска. Функция выкупа без недельного лимита — это пустой чек для любого повреждения баланса.

Внимательно подумайте о конкретных числах для вашего выхода. Это должно балансировать между максимально допустимым ущербом и потребностями пользователей. В случае проблем — это то, что спасет вас от полного краха.

Белый список (и черный список)

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

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

Возврат

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

Если никто не следит, аварийный выключатель бесполезен. Офлайн-мониторы должны постоянно отслеживать неподвижные свойства и автоматически поднимать тревогу при их нарушениях. Итоговая задача — передать управление человеку из команды стражей, предоставив ему достаточный контекст для быстрого решения.

Остановить и перенастроить

Если вас взломали, сначала остановитесь — остановите кровотечение, а не принимайте решения в спешке. Для протокола это — аварийный выключатель (должен отображаться в интерфейсе): одна кнопка, которая останавливает все пути перемещения ценностей. Подготовьте вспомогательный скрипт для «паузы всего» — перечислите все компоненты, которые можно приостановить, и сделайте это атомарно.

Только управление через governance может снять паузу, поэтому аварийный выключатель не должен останавливать сам governance-контракт. Если стражи могут приостанавливать governance — взломанный слой стражей может навсегда заблокировать восстановление.

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

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

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

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

Обдумывайте цепные реакции

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

Пауза должна быть полностью исследована, управляемой и недоступной для эксплуатации. Она должна замораживать весь протокол: вы не хотите, чтобы приостановка одного компонента открыла уязвимость другого. После выявления причины и вектора атаки — исследуйте все связанные поверхности и цепные реакции, и исправьте их одновременно.

Плановая ротация заранее объявленных преемников

Только заранее известные преемники обеспечивают безопасную ротацию. Мне нравится идея заранее зарегистрированного реестра преемников: он усложняет злоумышленнику замену здоровых стражей или управляемых кошельков на взломанные. Это согласуется с концепцией «белых/черных списков» в мерах смягчения.

Зарегистрируйте адрес преемника для каждого важного участника. Единственная команда, которая может инициировать замену — это «заменить роль X на преемника». Это позволяет в мирное время провести дью-дилидженс, оценить преемника и встретиться с ним.

Перед обновлением тщательно протестируйте

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

Не публикуйте обновление без достаточного тестирования. Если времени на аудит нет — используйте связи с белыми хакерами или запустите 48-часовой конкурс перед деплоем для получения свежей проверки.

Восстановление

Быстрые действия

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

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

Переговоры

Да, это болезненно, но стоит попытаться договориться с злоумышленником. Многие ситуации решаются через переговоры. Предложите ограниченную по времени награду для белых хакеров и публично объявите, что при полном возврате средств до определенного срока не будете подавать в суд.

Если вы сталкиваетесь с государственными субъектами — удача не на вашей стороне, но если злоумышленник — менее опытный, он просто использует уязвимость и хочет уйти за минимальные затраты.

Перед этим обязательно проконсультируйтесь с юристами.

Заключение

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