История криптовалютных взломов как история инженерных уроков

Один заголовок «взлом» скрывает разные инженерные истории

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

Сравним три хорошо задокументированных случая. Инцидент The DAO в 2016 году был связан с логикой смарт-контракта и рекурсивными вызовами. Ronin в 2022 году потерял средства после того, как злоумышленники получили контроль над достаточным числом валидаторских ключей для подписи вывода. В Nomad Bridge в том же году проблема возникла в проверке входящих сообщений после изменения реализации контракта. Эти события не сводятся к одной ошибке, но каждое показывает, как система доверия становится точкой отказа.

В этой статье «взлом» используется как привычное общее слово, а не как юридическое обвинение конкретного лица. Причины описаны на основании материалов самих команд, официальных документов и независимого технического анализа, доступных к 19 октября 2026 года. Если отчёт принадлежит проекту, это отмечено: официальный постмортем ценен первичными деталями, но остаётся самоописанием организации.

Главный вопрос не в том, какая сеть «самая безопасная». Нужно понять, какие классы ошибок повторяются: неправильная логика, недостаточно защищённые полномочия, доверие к внешней границе, несовпадение тестов с реальной конфигурацией и запоздалое обнаружение. Разбор этих классов полезнее, чем коллекция сенсационных сумм.

Ключи и хранение: когда корректная подпись подтверждает плохое действие

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

Ronin использовал валидаторов, чьи подписи совместно разрешали вывод средств из моста. В собственном постмортеме Sky Mavis описала компрометацию ключей большинства валидаторов и признала, что прежняя схема делегирования оставила лишний путь для получения дополнительной подписи. Команда сообщила об инциденте после того, как пользователь не смог вывести средства; задержка между транзакциями и обнаружением показала, что успешная проверка подписи не заменяет мониторинг аномальных сумм и поведения.

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

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

Ошибки контракта: маленькое условие с большим радиусом действия

The DAO собрал средства в смарт-контракте, который позволял участникам создавать дочерние структуры и выводить долю. 17 июня 2016 года Ethereum Foundation опубликовал предупреждение, что уязвимость рекурсивного вызова уже используется: повторный вызов функции в рамках операции позволял извлекать эфир до корректного обновления внутреннего баланса. Это был дефект конкретной программы The DAO, а не доказательство уязвимости каждого контракта Ethereum.

Ответ сообщества стал отдельной частью истории. В июле 2016 года Ethereum Foundation сообщил о проведённом хардфорке и переводе средств в recovery-контракт. Это было спорное коллективное решение на уровне сети, а не обычное исправление библиотеки. Часть участников не приняла изменение и продолжила исходную цепь, что стало Ethereum Classic. Техническое реагирование здесь повлекло политический вопрос: кто и при каких обстоятельствах вправе менять состояние блокчейна.

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

Практический вопрос — не «есть ли аудит?», а какая версия была проверена, какие функции и зависимости вошли в область работы, какие проблемы нашли и были ли изменения после заключения. Развёрнутый контракт может отличаться от исследованного исходного кода параметром, прокси-реализацией или изменением настройки. Прослеживаемость версии — часть безопасности.

Мосты: безопасность заканчивается там, где система перестаёт проверять

Мост должен принять сообщение о событии в одной сети и разрешить действие в другой. Между этими шагами может находиться ретранслятор, набор подписантов, лёгкий клиент, optimistic-механизм или иной способ доказать событие. Каждый вариант делает разные предположения о том, кому можно доверять и как обнаруживать ложное сообщение.

В августе 2022 года Nomad опубликовал root cause analysis уязвимости Replica-контракта. Ошибка реализации привела к тому, что некоторые сообщения проходили аутентификацию при неправильно обработанном значении корня. После первой успешной эксплуатации другие участники повторяли похожие операции с изменёнными получателями. Инцидент показывает два слоя риска: ошибку проверки, а затем доступность повторяемого шаблона действий для множества адресов.

Сам Nomad отдельно отметил границу своих watcher-систем: они наблюдали за компрометацией updater-ключа, но не выявляли подозрительные действия, возникавшие из-за дефекта контракта. Команда остановила обработку сообщений и рекомендовала не пользоваться мостом до исправления и перезапуска. Это не делает наблюдателей бесполезными; это демонстрирует, что контроль, построенный под одну модель угроз, может пропустить другую.

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

Обновления, зависимости и человеческий процесс

Безопасность — не только свойства кода, но и путь от изменения до production. Разработчик может корректно исправить одну проблему и внести другую при обновлении прокси, изменении параметров или включении новой функции. Аудит определённого commit не автоматически распространяется на последующие версии. Развёртывание требует подтверждения, что проверенный код, конфигурация и адрес контракта совпадают с тем, что работает в сети.

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

После инцидента команда должна быстро ограничить ущерб, сохранить доказательства, определить затронутые контракты, сообщить пользователям проверенную информацию и согласовать действия с партнёрами. NIST SP 800-61 Rev. 3 (2025) описывает цикл подготовки, обнаружения, анализа, сдерживания, восстановления и извлечения уроков для компьютерных инцидентов. Это руководство не написано специально для блокчейнов, но помогает задать организационные вопросы: кто принимает решение, что логируется, как проверить восстановление и как не потерять данные расследования.

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

Аудит снижает неопределённость, но не выдаёт сертификат неуязвимости

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

Материалы Nomad показывают, почему чтения кода недостаточно без проверки обстоятельств развёртывания. Root cause analysis объясняет, как условие контракта привело к неправильной обработке сообщений. Технический анализ Mandiant затем изучает ход эксплойта и транзакции после компрометации, добавляя независимую перспективу. Эти источники дополняют, но не заменяют друг друга: проект лучше знает внутренние решения, независимый исследователь может независимо проверить поведение цепочки.

Надёжная практика включает ревью архитектуры, тестирование негативных сценариев, проверку прав доступа, контроль обновлений, наблюдение за необычными операциями, лимиты ущерба и репетицию аварийного отключения. Меры стоит сопоставлять с реальной моделью угроз. Например, watcher, который умеет обнаружить потерю ключа, не обязательно распознает логическую ошибку; мультиподпись не помогает, если все ключи под контролем одной стороны; пауза уменьшает ущерб, но создаёт риск злоупотребления централизацией.

После вывода исправления требуется повторная независимая проверка изменённого кода и конфигурации. Обещание «мы прошли аудит» слишком общее, если не указаны аудиторы, дата, commit, область и способ устранения найденных замечаний. Вопрос безопасности — не бинарный штамп, а непрерывное управление остаточным риском.

Вывод: изучать не только ошибку, но и границу контроля

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

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

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

Источники

1. Ethereum Foundation: Critical Update Re: DAO Vulnerability (2016-06-17) — Первичное предупреждение о рекурсивном вызове в контракте The DAO.
2. Ethereum Foundation: Hard Fork Completed (2016-07-20) — Официальное описание хардфорка и recovery contract.
3. Ronin Network: Back to Building — Security Breach Postmortem (2022) — Первичное описание инцидента, его причин и мер команды.
4. Nomad: Bridge Hack Root Cause Analysis (2022-08-05) — Первичный отчёт об ошибке аутентификации Replica contract и границе watcher-систем.
5. Mandiant: Dissecting the Nomad Bridge Hack (2022-11-29) — Независимый анализ эксплойта и последующих транзакций.
6. NIST SP 800-61 Rev. 3: Incident Response Recommendations (2025-04-03) — Актуальное на cutoff руководство по подготовке, обнаружению, реагированию и восстановлению; не криптоспецифично.

Описание инцидентов основано на публичных технических материалах; причинная ответственность конкретных лиц не выводится из этих отчётов.