Оригинальный заголовок: Как прекратить терять деньги из-за взломов DeFi
Автор оригинала: sysls, openforage
Перевод и компиляция: AididiaoJP, Foresight News
Введение
Изучая множество случаев взломов DeFi-протоколов, у меня возникла тревога по поводу «государственных субъектов». Они обладают высокой технической подготовкой, ресурсами и играют в очень долгосрочную игру; эти суперзлодеи сосредоточены на поиске уязвимостей в каждом уголке ваших протоколов и инфраструктуры, в то время как обычные команды протоколов отвлечены на шесть-семь различных бизнес-направлений.
Я не считаю себя экспертом по безопасности, но я руководил командами в условиях высокого риска (включая военные и финансовые сферы с крупными капиталами), обладаю богатым опытом в планировании и разработке аварийных сценариев.
Я искренне верю, что выживают только упертые. Ни одна команда изначально не думает: «Я буду относиться к безопасности легкомысленно и халатно»; однако взломы всё равно происходят. Нам нужно делать лучше.
ИИ означает, что в этот раз всё действительно по-другому
(Источник данных: https://defillama.com/hacks)
Взломы не редкость, но их частота явно растет. Первый квартал 2026 года стал рекордным по количеству взломов DeFi, а второй квартал только начался, и уже обещает побить рекорд предыдущего.
Мое основное предположение: ИИ значительно снизил стоимость поиска уязвимостей и расширил поверхность атаки. Человеку требуется несколько недель, чтобы просмотреть конфигурации ста协议 и найти ошибочные настройки; а современные базовые модели могут сделать это за несколько часов.
Это должно кардинально изменить наш подход к размышлениям и реагированию на взломы. Старые протоколы, привыкшие к безопасности до появления мощных ИИ, всё больше рискуют быть «моментально уничтоженными».
Мышление через поверхности и уровни
(Источник данных: https://defillama.com/hacks)
Поверхности атаки на самом деле можно свести к трем: команда протокола, умные контракты и инфраструктура, границы доверия пользователей (DSN, социальные сети и т.п.).
Как только определены эти поверхности, добавляйте слои защиты:
· Предотвращение: строгое выполнение процедур, максимально снижающих вероятность эксплуатации.
· Смягчение: при неудаче предотвращения ограничить масштаб ущерба.
· Пауза: никто не способен принимать оптимальные решения под сильным давлением. После обнаружения атаки немедленно активируйте «тотальный выключатель». Заморозка может остановить дальнейшие потери и дать время на обдумывание……
· Восстановление: если контроль над вредоносными или взломанными компонентами утрачен, их нужно выбросить и заменить.
· Восстановление: вернуть утерянное. Заранее подготовьте контакты организаций, способных заморозить средства, отменить транзакции и помочь в расследовании.
Принципы
Эти принципы руководят конкретными действиями по реализации уровней защиты.
Массовое использование передовых ИИ
Массовое использование современных моделей ИИ для сканирования вашего кода и конфигураций, поиска уязвимостей и проведения красных командных тестов на поверхности: попытки найти уязвимости на фронтенде и проверить, могут ли они достичь бэкенда. Атакающие так делают. То, что вы можете обнаружить с помощью защитных сканирований, они уже нашли с помощью атакующих.
Используйте pashov, nemesis и другие навыки, а также платформы ИИ, такие как Cantina (Apex) и Zellic (V12), для быстрого сканирования кода до полного аудита.
Время и трение — хорошая защита
Добавляйте многоступенчатые процессы и тайм-ауты к любым операциям, способным нанести ущерб. Вам нужно достаточно времени, чтобы вмешаться и заморозить при обнаружении аномалий.
Ранее причины против тайм-аутов и многоступенчатых настроек сводились к тому, что это создает трение для команд протокола. Сейчас вам не стоит слишком беспокоиться: ИИ легко сможет пройти эти барьеры в фоновом режиме.
Непрерывные переменные
Умные контракты могут строиться на основе написания неизменяемых «фактов»: если эти факты нарушаются, вся логика протокола рушится.
Обычно у вас есть лишь несколько таких переменных. Их нужно аккуратно выводить на уровень кода; принудительное соблюдение нескольких переменных в каждом функции усложняет управление.
Баланс власти
Многие взломы происходят из-за компрометации кошельков. Вам нужно такую конфигурацию: даже если мультиподписи взломаны, можно быстро ограничить ущерб и вернуть протокол в управляемое состояние.
Это требует баланса между управлением (принятием решений) и спасением (восстановлением управляемой стабильности, без возможности отмены или свержения управления).
Всегда бывают проблемы
Изначально предположите: независимо от вашей умности, вас взломают. Ваши умные контракты или зависимости могут выйти из строя. Могут быть социальные инженерные атаки, новые обновления могут ввести неожиданные уязвимости.
Если так думать, то лимиты по ущербу и отключение протокола станут вашими лучшими друзьями. Ограничьте ущерб до 5-10%, затем заморозьте и спланируйте реакцию. Никто не способен принимать оптимальные решения под огнем.
Лучшее время для планирования — сейчас
Думайте о своих сценариях реагирования еще до взлома. По возможности автоматизируйте процессы и тренируйте команду, чтобы не паниковать в критический момент. В эпоху ИИ это означает обладать навыками и алгоритмами, способными максимально быстро предоставлять большие объемы информации, и делиться ими в кратком и расширенном виде с ключевыми участниками.
Вам не нужен идеальный план, но вы должны выжить. Ни одна система с первого дня не является непобедимой; через итерации и обучение вы станете более устойчивыми.
Отсутствие доказательств взлома не означает, что вас не взломают. Максимальная комфортная точка зачастую — это максимальная опасность.
Меры профилактики
Проектирование умных контрактов
После определения переменных, их нужно вывести на уровень проверки во время выполнения. Внимательно подумайте, какие переменные действительно стоит принудительно соблюдать.
Это и есть модель FREI-PI (Function Requirements, Effects, Interactions, Protocol Invariants): в конце каждой функции, затрагивающей ценность, повторно проверяйте обязательные переменные. Многие атаки типа CEI (Checks-Effects-Interactions), такие как флеш-лоаны, атаки на оракулы и межфункциональные выплаты, можно поймать именно этим методом.
Хорошее тестирование
Статистическое fuzz-тестирование (Stateful fuzzing) генерирует случайные последовательности вызовов, охватывающие весь публичный интерфейс протокола, и проверяет незыблемость переменных на каждом шаге. Большинство уязвимостей в реальных протоколах — это мульти-транзакционные, и статический fuzzing почти единственный надежный способ обнаружить такие пути до злоумышленника.
Используйте тесты на незыблемость для проверки, что свойства выполняются во всех возможных последовательностях вызовов, которые генерирует fuzz-тестер. В сочетании с формальной верификацией это доказывает, что свойства выполняются во всех достижимых состояниях. Ваши переменные «короны» должны проходить такую проверку.
Оракулы и зависимости
Сложность — враг безопасности. Каждый внешний источник расширяет поверхность атаки. При проектировании протокола дайте пользователю выбор, кому и чему доверять. Если зависимость не устранить, сделайте ее диверсифицированной, чтобы ни один сбой не мог полностью разрушить протокол.
Расширьте аудит, моделируя возможные сбои оракулов и зависимостей, и наложите ограничения на скорость их отказов и последствия.
Недавняя уязвимость KelpDAO — пример: они унаследовали конфигурацию LayerZero requiredDVNCount=1, которая вышла за рамки их аудита. В итоге взломали стороннюю инфраструктуру вне их аудита.
Поверхностные атаки
Большинство поверхностных атак в DeFi уже перечислены. Проверьте каждую категорию, спросите себя, применима ли она к вашему протоколу, и внедрите контроль для каждого вектора. Развивайте навыки red team, чтобы ваши ИИ-агенты самостоятельно искали уязвимости — это уже базовая практика.
Обеспечьте встроенные механизмы спасения
На основе голосования власть изначально сосредоточена в мультиподписях команды, и требуется время, чтобы распространить ее. Даже при широком распределении токенов, делегирование зачастую концентрирует власть в нескольких кошельках (иногда даже один). В случае их взлома игра окончена.
Разверните «кошельки-стражи», с жесткими ограничениями: они могут только приостанавливать протокол, а при >=4/7 голосов — в экстремальных случаях заменять поврежденные делегированные кошельки на заранее определенные. Стражи никогда не могут инициировать управленческие предложения.
Так вы получите слой спасения, который всегда сможет вернуть протокол в управляемое состояние, не давая возможности свергнуть управление. Вероятность потери >=4/7 стражей — очень мала (учитывая диверсификацию держателей), и по мере зрелости и децентрализации протокола этот слой можно постепенно убрать.
Кошельки и топология ключей
Мультиподписи — минимальный стандарт, минимум 4/7. Ни один человек не должен контролировать все 7 ключей. Регулярно меняйте подписантов, делая это незаметно.
Ключи никогда не должны взаимодействовать с повседневными устройствами. Если вы используете устройство для подписания, просматривая интернет, почту или Slack, считайте, что этот ключ уже взломан.
Используйте несколько мультиподписей для разных целей. Предположите, что хотя бы один из них будет взломан, и планируйте исходя из этого. Ни один человек не должен иметь достаточной власти, чтобы взломать протокол, даже в экстремальных ситуациях (похищение, пытки и т.п.).
Рассмотрите возможность использования бонусов
Если есть ресурсы, установите высокую награду за обнаружение уязвимостей, пропорциональную TVL протокола; даже для небольших протоколов награда должна быть щедрой (минимум 7-8 цифр).
Если вы сталкиваетесь с государственными субъектами, они могут не вести переговоры, но вы можете участвовать в программе «белых шляп» — разрешить белым хакерам действовать от вашего имени для защиты средств, взимая процент с найденных уязвимостей (фактически — награду, оплачиваемую вкладчиками).
Выбор хороших аудиторов
Я ранее писал, что с развитием больших языковых моделей ценность найма аудиторов снижается. Я всё еще придерживаюсь этого мнения, но мои взгляды изменились.
Во-первых, хорошие аудиторы идут впереди кривой. Если вы делаете что-то новое, ваш код и его уязвимости могут не попасть в их обучающие данные, и просто увеличение количества токенов пока не доказало эффективность в обнаружении новых уязвимостей. Вы не хотите стать первым образцом для уникальных уязвимостей.
Во-вторых, недооцененная выгода — это то, что нанимая аудиторов, вы используете их репутацию как гарантию. Если они подпишут и вы будете взломаны, они будут сильно мотивированы помочь. Установление отношений с профессионалами в области безопасности — огромное преимущество.
Практика операционной безопасности
Рассматривайте операционную безопасность как ключевой показатель успеха. Проводите тренировки по фишингу; нанимайте (доверенных) red team для социальной инженерии. Имейте запасные аппаратные кошельки и устройства, чтобы при необходимости быстро заменить весь мультиподпись. Не стоит в критический момент искать их в магазине.
Меры смягчения
Ваш путь выхода — это лимит потерь
Любой путь вывода средств из протокола должен иметь верхнюю границу — максимально возможный ущерб при использовании уязвимости. Проще говоря: функция эмиссии без лимита по блокам — это пустой чек на неограниченную эмиссию. Функция выкупа без недельного лимита — это пустой чек на любые остатки.
Внимательно подумайте о конкретных числах для вашего пути выхода. Это должно балансировать между максимально допустимым ущербом и потребностями пользователей. В случае проблем, это — то, что спасет вас от полного краха.
Белый список (и черный список)
Большинство протоколов имеют списки вызываемых функций, транзакций или получателей, а также списки, которым пользователи не должны доверять. Даже если эти списки не явно задекларированы, они — границы доверия и должны быть формализованы.
Формализовав их, вы сможете внедрить двухэтапные механизмы установки, создавая значительное трение. Атакающий сначала должен добавить себя в белый список (или убрать из черного), а затем действовать. Одновременно наличие обоих списков усложняет злоумышленнику скрытное внедрение новых векторов: рынок должен быть открыт (интеграция/листинг), и действия не должны быть запрещены (проверка безопасности).
Восстановление
Мониторинг алгоритмов
Если никто не следит, «убийственный» выключатель бесполезен. Внепрограммный монитор должен постоянно следить за незыблемостью переменных и, при обнаружении проблем, автоматически поднимать тревогу. Итоговая реакция должна доходить до человека, управляющего мультиподписями, и содержать достаточно контекста для быстрого принятия решения.
Перезагрузка и перенастройка
Если вас взломали, сначала остановите кровотечение, а не принимайте решения в спешке. Для протокола это — «убийственный» выключатель (должен отображаться в интерфейсе): кнопка, которая мгновенно приостанавливает все перемещения ценностей. Подготовьте вспомогательный скрипт «пауза всего», который перечисляет все компоненты, подлежащие приостановке, и делает это атомарно.
Только управление может снять блокировку — «убийственный» выключатель не должен останавливать сам управляющий контракт. Если слой стражей может приостанавливать управляющий контракт, взломанный слой стражей может навсегда заблокировать восстановление.
Запустите командный центр
Заморозьте, остановите кровотечение, а затем соберите всех доверенных лиц (с заранее согласованными ролями) в канал связи. Желательно держать информацию максимально закрытой, чтобы не дать злоумышленникам, публике или арбитражникам воспользоваться ею.
Распределите роли: один принимает решения; один — опытный оператор, выполняющий скрипты защиты и приостановки; один — специалист по анализу уязвимостей и поиску коренных причин; один — связующее лицо с ключевыми сторонами; один — человек, фиксирующий события, решения и таймлайны.
Когда все знают свои роли и отрепетировали сценарии, вы сможете реагировать по плану, а не паниковать в самый критический момент.
Рассмотрите цепные реакции
Предположим, ваш злоумышленник очень опытен. Первый уязвимый компонент может быть приманкой или заделом для следующей атаки. Атака может быть спланирована так, чтобы заставить вас сделать что-то полностью неправильное, что откроет доступ к настоящей уязвимости.
Пауза должна быть полностью исследована, управляемой и недоступной для эксплуатации. Она должна означать полное замораживание протокола: вы не хотите, чтобы приостановка одного компонента привела к открытию другого. После выявления корня и вектора атаки, необходимо исследовать смежные поверхности и цепные реакции, и устранить все сразу.
Планируйте заранее смену доверенных лиц
Только при предварительном знании преемников можно безопасно осуществлять ротацию. Мне нравится идея заранее зарегистрированного реестра преемников: это усложняет злоумышленнику замену здоровых стражей или управляемых кошельков на взломанные. Это согласуется с концепцией «белых/черных списков» в мерах смягчения.
Зарегистрируйте адрес преемника для каждого важного участника. Единственная команда, которая может выполнить замену — «заменить роль X на ее преемника». Это позволяет в спокойной обстановке провести дью-дилидженс, подготовиться и встретиться с кандидатами.
Тщательное тестирование перед обновлением
После определения корня и масштабов воздействия необходимо подготовить обновление. Это — самый опасный код, который вы собираетесь внедрить: написанный под давлением, с учетом того, что злоумышленник уже знает ваш протокол и ищет уязвимости.
Не торопитесь с выпуском без достаточного тестирования. Если времени на аудит нет, используйте связи с белыми хакерами или проведите 48-часовой конкурс перед деплоем для получения свежей экспертной оценки.
Восстановление
Быстрые действия
Потери при взломе имеют полувременную характеристику; как только уязвимость реализована, деньги быстро попадают в отмывочные схемы. Заранее подготовьте инструменты типа Chainalysis для анализа цепочек, чтобы в реальном времени отслеживать адреса злоумышленников и при их межцепочечных перемещениях уведомлять биржи и службы безопасности.
Заранее подготовьте список доверенных сторон: централизованных бирж, администраторов мостов, хранителей и других третьих лиц, способных заморозить межцепочечные сообщения или депозиты в пути.
Переговоры
Да, это болезненно, но всё равно стоит попытаться договориться с злоумышленниками. Многие ситуации решаются через переговоры. Предложите ограниченную по времени награду белым хакерам и публично объявите, что при полном возврате средств до срока не будете подавать в суд.
Если вы сталкиваетесь с государственными субъектами, у вас может не получиться договориться, но вы можете участвовать в программе «белых шляп» — разрешить белым хакерам действовать от вашего имени для защиты средств, взимая процент с найденных уязвимостей (фактически — награду, оплачиваемую вкладчиками).
Обязательно привлеките юристов перед этим.
Итог
Взломы не прекратятся, и с развитием ИИ их станет только больше. Просто делать защиту «более чуткой» недостаточно. Нам нужно использовать те же инструменты, что и злоумышленники, — проводить красные команды, постоянный мониторинг и жесткие лимиты ущерба, чтобы выжить в худших сценариях.
Ссылка на оригинал
Узнайте о вакансиях в BlockBeats на сайте
Присоединяйтесь к официальному сообществу BlockBeats:
Подписка в Telegram: https://t.me/theblockbeats
Группа в Telegram: https://t.me/BlockBeats_App
Официальный аккаунт в Twitter: https://twitter.com/BlockBeatsAsia
