Как взламывают крипто-мосты: постмортем восьми инцидентов

Мосты (bridges) взламывают, потому что они отвечают на вопрос, который ни одна блокчейн-сеть не может проверить самостоятельно: действительно ли что-то произошло в другой сети? Каждая крупная потеря через мост сводится к тому, что на этот вопрос был дан неверный ответ из-за скомпрометированного ключа, поддельного доказательства, оффчейн-сервиса, получившего ложные данные, или разрешения, которое не было отозвано. Суммы различаются; класс ошибки – нет.

Паттерн за каждой крупной потерей через мост

Мост удерживает стоимость в одной сети и выпускает равное количество активов в другой, поэтому его корректность зависит от межсетевого инварианта (cross-chain invariant), а не от одного контракта. Когда инвариант нарушается, активы, выпущенные на стороне назначения, не имеют обеспечения на стороне источника.

Межсетевой инвариант: бухгалтерское правило, согласно которому активы, выпущенные в целевой сети, должны равняться сожженным или заблокированным активам в исходной сети. Merkle proof (меркловое доказательство): компактное доказательство того, что транзакция была включена в блок, которое проверяет мост перед выпуском средств. DVN (Decentralized Verifier Network / Децентрализованная сеть верификаторов): оффчейн-сервис, который наблюдает за одной сетью и удостоверяет сообщение, чтобы другая сеть могла действовать на его основе.

Почти каждый инцидент сводится к одному из четырех классов ошибок:

• Компрометация ключей: злоумышленники владеют достаточным количеством ключей валидаторов для подписания мошеннического вывода.
• Ошибка в пути проверки: контракт принимает аттестацию, которую он должен был отклонить.
• State-as-data (состояние как данные): оффчейн-верификатор получает ложные данные исходной сети из-за зараженной инфраструктуры.
• Операционный долг: разрешение, белый список или значение по умолчанию, которые следовало закрыть месяцами ранее.

Терминология более широкого стека остается в глоссарии блокчейна; в этом разделе приведено только то, что необходимо для аргументации.

Инциденты и код, который дал сбой

Фигуры ниже взяты из публичных трекеров эксплойтов и отчетов об инцидентах. Столбец «Loss» (потери) фиксирует сумму, украденную в момент инцидента, а не то, что проект потерял в конечном итоге; если источники расходятся в суммах, в таблице приводится одна цифра, а не диапазон.

Три строки заслуживают более подробного чтения, так как каждая из них – урок, который индустрия уже оплатила.

Ronin – это случай операционного долга. Девять валидаторов могли подписывать, требовалось пять подписей, и Sky Mavis управляла четырьмя из них. Пятый был доступен через делегирование, предоставленное Axie DAO во время всплеска транзакций; делегирование должно было быть временным, но белый список никогда не был отозван, поэтому компрометация собственных систем оператора было достаточно для достижения кворума.

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

Ни один ключ подписи не был скомпрометирован, ни один контракт не содержал ошибки, и каждая ончейн-транзакция была индивидуально действительна. Мост был приостановлен в течение часа, что предотвратило повторную попытку выпустить еще 40 000 rsETH, но первый выпуск уже был утрачен.

Verus-Ethereum – это случай нарушения связи стоимости. Около $11,6 млн покинули мост после поддельного межсетевого сообщения о переводе, и полученные средства позже были обменены примерно на 5 402 ETH. Около 75% из этой суммы, около 4 052 ETH, вернулись проекту в течение нескольких дней после того, как он предложил вознаграждение в размере 1 350 ETH, которое злоумышленник сохранил. Заявленная корневая причина – это не ошибка подписи или ключа, а отсутствующая проверка того, что сумма, заблокированная на стороне источника, совпадает с суммой, выплаченной на Ethereum: криптографическое доказательство включения было действительным, а экономическое утверждение, которое оно несло, – нет.

Почему «протестировано аудитом» не означает безопасно

Аудит смарт-контракта рассматривает путь кода и, по конструкции, не видит инфраструктуру, которая решает, какие данные передаются коду. Этот пробел стал причиной крупнейшей потери класса state-as-data: KelpDAO.

• Аудиты охватывают контракты, а не конечные точки RPC, наборы подписантов или гигиену операторов под ними.
• Терпят неудачу предположения: верификатор, доверяющий своему источнику данных, честен ровно настолько, насколько честен этот источник.
• Экономический дизайн усиливает ошибку кода: когда проверка подписи неверна, потери равны тому, что мост может отчеканить.
• Два последних инцидента тянут в противоположных направлениях. KelpDAO произошел из-за инфраструктуры и оставил контракт нетронутым; Verus произошел из-за пробела в проверке в коде моста. Укрепление одного из них не укрепляет другое.

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

Что фактически снижает риск

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

1. Требуйте M-of-N аттестацию от независимых операторов, а не N-of-N от стека одного вендора.
2. Диверсифицируйте источники данных, от которых читает верификатор, и подавайте сигнал тревоги, когда они расходятся, вместо того чтобы молча переключаться на резервный.
3. Мониторьте сам инвариант: сопоставляйте каждый выпуск с сожжением и подавайте сигнал тревоги при первом несопоставленном событии.
4. Тестируйте обновления с кейсами fail-closed (отказ в работе при ошибке); нулевой корень Nomad был принят, потому что никто не попробовал случай пустого сообщения.
5. Пересматривайте делегирования и белые списки по расписанию; каждое временное разрешение остается постоянным риском, пока оно не будет отозвано.
6. Ограничьте стоимость, которую может выпустить одно сообщение, чтобы ошибка стоила доли, а не всего эскроу.
7. Сохраняйте возможность приостановки и подтвердите, кто может выполнить эту приостановку в три часа ночи.

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

Чек-лист проверки для любого, использующего мост

Пройдите эти пять проверок, прежде чем доверять мосту свои средства, и запишите ответы вместе с датой.

• Посчитайте верификаторов: сколько независимых аттестаций требуется и кто ими управляет?
• Отследите путь данных: какие конечные точки RPC и провайдеры питают верификатор и что происходит при отказе?
• Прочтите журнал изменений: когда было последнее изменение конфигурации и было ли временное разрешение отозвано afterwards?
• Проверьте мониторинг инвариантов: может ли сам мост обнаружить выпуск безmatching сожжения и как быстро?
• Проверьте выход: какова максимальная стоимость, которую может выпустить одно сообщение и кто может приостановить мост?

Ответы меняются со временем; вопросы нет, именно поэтому дата ответа имеет такое же значение, как и сам ответ. Как одна конечная точка становится границей доверия, является предметом разбора работы blockchain RPC.

Частые вопросы

Какой самый крупный взлом крипто-моста в истории?

Ronin Bridge остается самой крупной зафиксированной потерей через мост – около $624 млн в марте 2022 года, опережая Poly Network на $611 млн и BNB Bridge на около $586 млн.

Обратите внимание, что скрывает рейтинг: Ronin был сбоем управления ключами, Poly Network – сбоем контроля доступа, и у них нет ничего общего, кроме размера числа.

Мосты все еще взламывают?

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

Повторная попытка в том инциденте была заблокирована приостановкой, которая стала контролем, определившим финальный размер потерь.

Что такое конфигурация DVN 1-of-1 и почему она опасна?

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

Мультиподпись с одним требуемым подписантом – это одна подпись с лишними шагами, и та же логика применяется к любому мосту, чей порог кворума равен одному.

Предотвращают ли аудиты взломы мостов?

Нет, но сбои различаются: KelpDAO произошел из-за инфраструктуры вне границы аудита, в то время как Verus был отсутствующей проверкой внутри контракта, поэтому требуются и аудит, и обзор инфраструктуры.

Аудиты остаются необходимыми; отсутствует обзор уровня инфраструктуры, проводимый по тем же стандартам.

Что должен сделать пользователь, чтобы снизить воздействие?

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

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