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