Уязвимости в безопасности мостов

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

Основы

Слабые места в безопасности мостов часто связаны с недостаточной on-chain и off-chain валидацией, неправильным обращением с нативными токенами и некорректной конфигурацией. Для надежной логики верификации рекомендуется тщательное тестирование моста против различных векторов атак.

Что такое блокчейн-мост?

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

Мосты реализуют различные on-chain и off-chain механизмы валидации, критически важные для межцепочной совместимости. Соответственно, у них появляются специфические уязвимости в части безопасности.

Почему важна безопасность мостов?

По оценкам отрасли, атаки на мосты привели к потерям около 1,3 млрд USD в 2022 году, что составило 36% всех потерь за тот год. Атакам в первую очередь подвержены кросс-чейн-приложения, поскольку мосты, часто реализуемые как смарт-контракты, аккумулируют значительные суммы токенов при их перемещении между цепями. Это делает мосты привлекательной целью для хакеров.

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

Уязвимости, связанные с мостами

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

У некоторых мостов снижён акцент на on-chain валидации, особенно если они ориентированы на конкретные DApp. Такие мосты полагаются на централизованный бэкенд для выполнения основных операций: mint, burn и переводов токенов, при этом валидация проводится off-chain.

Другие мосты используют смарт-контракты для валидации сообщений и проверок on-chain. Когда пользователь депонирует средства в цепочку, смарт-контракт генерирует подписанное сообщение и включает подпись в транзакцию. 

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

Тем не менее, если во время on-chain валидации присутствует уязвимость, атакующий может её эксплуатировать и нанести серьёзный вред. Например, в мосте, использующем дерево Меркла для валидации записей транзакций, злоумышленник мог бы подделать доказательства. Это позволило бы обойти валидацию и нелегально сгенерировать новые токены на свой счёт, воспользовавшись слабостью логики проверки.

Обёрнутые токены и безопасность мостов

Некоторые мосты используют так называемые «wrapped tokens» — обёрнутые токены. Например, при переводе DAI из Ethereum в BNB Chain ваши DAI списываются из контракта в Ethereum, а эквивалентное количество обёрнутых DAI создаётся в BNB Chain.

Однако при недостаточной валидации транзакции злоумышленники могут эксплуатировать систему. Развернув вредоносный контракт и манипулируя его функциями, они способны перенаправить обёрнутые токены с моста на свой адрес.

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

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

Слабая off-chain валидация и безопасность мостов

В некоторых системах роль проверки сообщений с блокчейна возложена на off-chain бэкенд-сервер. Здесь речь о верификации депозит-транзакций. 

Мост с off-chain валидацией работает так: 

• Пользователи взаимодействуют с DApp и депонируют токены в смарт-контракт в исходной цепи.
• DApp отправляет хеш транзакции депозита на бэкенд-сервер через API.
• Сервер выполняет ряд проверок хеша транзакции. Если транзакция легитимна, подписант формирует подпись и отправляет её обратно интерфейсу через API.
• Получив подпись, DApp проверяет её и разрешает пользователю вывести токены в целевой цепи.

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

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

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

Неправильная обработка нативных токенов

Мосты по-разному работают с нативными и utility-токенами. В Ethereum нативным токеном является ETH, тогда как большинство utility-токенов соответствуют стандарту ERC-20. Чтобы перенести ETH на другую цепь, пользователь должен депонировать ETH в контракт моста, прикрепив ETH к транзакции и прочитав сумму из поля "msg.value".

Депозит ERC-20 токенов отличается: пользователю нужно разрешить контракту моста тратить свои токены. После депозита контракт либо "сожжёт" токены пользователя через функцию "burnFrom()", либо переведёт их в свой баланс с помощью "transferFrom()".

Существуют разные подходы для различения сценариев. Один метод — использовать if-else в одной функции, другой — отдельные функции для каждого случая. Важно не пытаться депонировать ETH через ERC-20-функцию депозита, так как это может привести к потере средств.

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

Тем не менее проблемы возникают при кросс-чейн-переводе нативных токенов, у которых нет адреса. Нативный токен обозначается нулевым адресом (0x000...0). Это может быть проблемой, поскольку передача нулевого адреса в функцию может обойти проверку белого списка при некорректной реализации.

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

Риски из-за неверной конфигурации

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

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

Как повысить безопасность мостов

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

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

Заключение 

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