Эта статья представляет собой сообщение сообщества. Автор — Минжи Хэ, аудитор компании CertiK.
Мнения, выраженные в этой статье, принадлежат автору/участнику и не обязательно отражают точку зрения Binance Academy.
Краткое содержание
Мосты блокчейна важны для достижения совместимости в области блокчейна. Поэтому безопасность моста очень важна. Некоторые распространенные уязвимости безопасности мостов включают слабую проверку внутри и вне цепочки, неправильную обработку собственных токенов и неправильную конфигурацию. Рекомендуется протестировать мост против всех возможных векторов атак, чтобы обеспечить разумную логику проверки.
Введение
Bridge-блокчейн — это протокол, который соединяет два блокчейна, обеспечивая взаимодействие между ними. Если у вас есть биткойны, но вы хотите участвовать в деятельности DeFi в сети Ethereum, мосты блокчейна позволят вам сделать это без продажи биткойнов.
Мосты блокчейна необходимы для достижения совместимости в области блокчейна. Этот мост функционирует с использованием различных проверок внутри и вне цепочки, поэтому он имеет различные уязвимости безопасности.
Почему важна безопасность моста?
Мосты обычно хранят токены, которые пользователи хотят перенести из одной цепочки в другую. Мосты часто реализуются в виде смарт-контрактов и хранят большие объемы токенов по мере накопления межцепочных переводов, что делает их заманчивыми целями для хакеров.
Кроме того, мосты блокчейна имеют большой пробел в атаках, поскольку они включают в себя множество компонентов. Таким образом, преступники очень заинтересованы в использовании кросс-чейн-приложений для хищения больших сумм средств.
По оценкам CertiK, атаки на мосты нанесли ущерб в размере более 1,3 млрд долларов США в 2022 году, что составляет 36% от общих потерь за этот год.
Распространенные уязвимости безопасности мостов
Чтобы повысить безопасность мостов, важно понимать общие уязвимости безопасности мостов и тестировать мосты перед запуском. Эти уязвимости можно разделить на четыре области.
Слабая проверка в цепочке
Для простых мостов, особенно тех, которые предназначены для конкретных DApps, проверка на цепочке минимальна. Мост опирается на централизованный бэкэнд для выполнения основных операций, таких как чеканка, запись и передача токенов, при этом вся проверка выполняется вне цепочки.
Напротив, другие типы мостов используют смарт-контракты для проверки сообщений и выполнения проверки в цепочке. В этой ситуации, когда пользователь вносит средства в цепочку, смарт-контракт сгенерирует подписанное сообщение и вернет подпись в транзакции. Эта подпись служит доказательством депозита и используется для проверки запросов пользователей в других цепочках. Этот процесс должен предотвратить различные атаки на безопасность, включая атаки повтора и поддельные записи о депозитах.
Однако если во время процесса проверки цепочки существует уязвимость, злоумышленник может нанести серьезный ущерб. Например, если мост использует дерево Меркла для проверки записей транзакций, злоумышленник может создать ложные доказательства. Это означает, что они могут обойти проверку подтверждения и создать новые токены для своей учетной записи, если процесс проверки уязвим.
Некоторые мосты реализуют концепцию «обернутого токена». Например, когда пользователь переносит DAI из Ethereum в BNB Chain, его DAI берется из контракта Ethereum, и эквивалентное количество завернутого DAI выдается в BNB Chain.
Однако, если эти транзакции не проверены должным образом, злоумышленник может реализовать вредоносный контракт для маршрутизации завернутых токенов с моста на неправильный адрес, манипулируя его функциональностью.
Злоумышленник также требует от жертвы согласия с бридж-контрактом, чтобы передавать токены с помощью функции «transferFrom» для вывода активов из бридж-контракта.
К сожалению, ситуация усугубляется, поскольку большинство мостов требуют неограниченного одобрения токенов от пользователей DApp. Это обычная практика, которая снижает комиссию за газ, но вносит дополнительный риск, позволяя смарт-контрактам получать доступ к токенам из неограниченного количества пользовательских кошельков. Злоумышленники могут использовать отсутствие проверки и чрезмерное одобрение для передачи токенов от других пользователей себе.
Слабая внесетевая проверка
В некоторых мостовых системах внесетевые серверы играют важную роль в проверке достоверности сообщений, отправленных из блокчейна. В данном случае мы ориентируемся на проверку депозитных операций.
Принцип работы моста блокчейна с проверкой вне сети выглядит следующим образом:
Пользователи взаимодействуют с DApp для внесения токенов в смарт-контракты в исходной цепочке.
Затем DApp отправляет хэш транзакции депозита на внутренний сервер через API.
Хэши транзакций требуют некоторой проверки со стороны сервера. Если подпись считается действительной, подписывающая сторона подписывает сообщение, а затем отправляет подпись обратно в пользовательский интерфейс через API.
После получения подписи DApp проверяет ее, а затем позволяет пользователю вывести токены из целевой цепочки.
Внутренний сервер должен гарантировать, что обработанная депозитная транзакция действительно произошла и не была подделана. Этот внутренний сервер определяет, могут ли пользователи выводить токены в целевой цепочке, что делает ее ценной целью для злоумышленников.
Внутренний сервер должен проверить структуру событий, возникшую в результате транзакции, а также адрес контракта, который сгенерировал событие. Если адрес контракта игнорируется, злоумышленник может реализовать вредоносный контракт для подделки события депозита, используя ту же структуру, что и законное событие депозита.
Если он не проверяет адрес, вызвавший событие, внутренний сервер может предположить, что этот контракт действителен, и подписать сообщение. Затем злоумышленник может отправить хэш транзакции на бэкэнд, тем самым минуя проверку и позволяя вывести токены из целевой цепочки.
Неправильная обработка собственных токенов
Bridge использует различные подходы к работе с собственными и служебными токенами. Например, в сети Ethereum собственным токеном является ETH, а большинство служебных токенов соответствуют стандарту ERC-20.
Когда пользователь намеревается перевести свой ETH в другую цепочку, он должен сначала внести его в мостовой контракт. Для этого пользователи просто прикрепляют 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 не несет ответственности за любые убытки, которые вы можете понести. Этот материал не следует рассматривать как финансовую, юридическую или другую профессиональную консультацию. Для получения дополнительной информации прочтите наши Условия использования и Предупреждение о рисках.