Какие распространённые уязвимости безопасности при межцепочечном мостировании?

摘要

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

Введение

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

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

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

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

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

По оценкам CertiK, в 2022 году атаки на блокчейн-мосты привели к потерям свыше 1,3 миллиарда долларов, что составляет 36% от общего ущерба за год.

Распространённые уязвимости в безопасности межцепочечных мостов

Для повышения безопасности блокчейн-мостов важно знать распространённые уязвимости и тестировать их до запуска. Эти уязвимости в основном связаны с четырьмя аспектами:

Недостаточная проверка на стороне цепочки

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

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

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

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

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

Злоумышленник также должен получить предварительное одобрение жертвы для использования функции “TransferFrom” в межцепочечном мосту, чтобы вывести активы и похитить их.

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

Недостаточная проверка вне цепочки

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

Работа системы с проверкой вне цепочки следующая:

Пользователь взаимодействует с dApp, вносит токены в смарт-контракт на исходной цепочке.

Затем dApp через API отправляет хэш транзакции пополнения на сервер.

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

После получения подписи, dApp проверяет её и разрешает пользователю вывести токены на целевой цепочке.

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

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

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

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

Межцепочечные мосты используют разные подходы к обработке нативных и утилитарных токенов. Например, в сети Ethereum нативный токен — ETH, большинство утилитарных токенов — ERC-20.

Если пользователь хочет перевести ETH на другую цепочку, он должен сначала внести его в смарт-контракт моста. Для этого он просто добавляет ETH к транзакции, и количество ETH можно определить по полю “msg.value”.

Внесение ERC-20 токенов существенно отличается. Перед этим пользователь должен разрешить мосту использовать его токены. После одобрения и внесения токенов в контракт, он вызывает функцию “burnFrom(” для сжигания своих токенов или “transferFrom)” для перевода токенов на контракт.

Чтобы отличить эти операции, можно использовать условные конструкции if-else в одном и том же функции или создать отдельные функции для каждого сценария. Из-за различий в обработке, если пользователь попытается внести ETH через функцию для ERC-20, он потеряет свои средства.

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

Однако при обработке нативных токенов, у которых нет адреса, используют специальный адрес — “нулевой адрес” (0x000…000). Но если логика проверки белого списка реализована неправильно, передача нулевого адреса может обойти проверку.

Когда мост вызывает “TransferFrom” для перевода активов пользователя на контракт, вызов с нулевым адресом вернёт false, так как у нулевого адреса не реализована функция “transferFrom”. Но если контракт неправильно обрабатывает возвращаемое значение, транзакция всё равно может пройти, что даст злоумышленнику возможность выполнить транзакцию без перевода токенов.

Ошибки конфигурации

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

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

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

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

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

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

Заключение

Из-за огромных объёмов средств, находящихся в них, межцепочечные мосты остаются долгие годы мишенью для злоумышленников. Разработчики могут повысить безопасность мостов, проводя всесторонние тесты перед запуском и привлекая сторонние аудитории, что снижает риск катастрофических хакерских атак, охвативших их за последние годы. В мире мультицепочечных сетей безопасность должна быть приоритетом при проектировании и создании эффективной инфраструктуры Web3. ($STO