Эта статья предоставлена ​​сообществом. Автор — Минжи Хэ, аудитор CertiK.

Мнения в этой статье принадлежат автору/участнику и не обязательно отражают точку зрения Binance Academy.

ТЛ;ДР

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

Введение 

Мост блокчейна (или «мост блокчейна») — это протокол, который соединяет два блокчейна, обеспечивая взаимодействие между ними. Если у вас есть биткойны, но вы хотите участвовать в деятельности DeFi в сети Ethereum, мост блокчейна позволит вам сделать это без необходимости продавать свои биткойны. 

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

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

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

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

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

Распространенные уязвимости безопасности моста

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

Слабая проверка в цепочке

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

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

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

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

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

Хакерам нужно, чтобы жертвы одобрили мостовой контракт для передачи токенов с помощью функции «transferFrom» и кражи активов контракта. 

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

Слабая внесетевая проверка

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

Мост блокчейна с оффчейн проверкой работает следующим образом: 

  1. Пользователи взаимодействуют с DApp для внесения токенов в смарт-контракт в исходной цепочке блоков.

  2. Затем DApp отправляет хэш транзакции депозита на внутренний сервер через API.

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

  4. Получив подпись, DApp проверяет ее и позволяет пользователю вывести свои токены из исходной цепочки блоков.

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

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

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

Плохое управление собственными токенами

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

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

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

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

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

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

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

Неправильная конфигурация

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

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

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

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

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

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

Заключительные соображения 

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

дальнейшее чтение

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

Что такое межсетевое взаимодействие?

Три популярных криптомоста и как они работают

Что такое упакованные токены?

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