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

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

Краткое содержание

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

Введение

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

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

Почему безопасность мостов блокчейна имеет решающее значение?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Что такое завернутый токен?

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