Эта статья написана сообществом. Автор: Минжи Хэ, аудитор компании CertiK.
Мнения, описанные в этой статье, принадлежат автору/создателю и необязательно отражают точку зрения Binance Academy.
Осторожно! Много текста.
Блокчейн-мосты стали ключом к достижению совместимости в пространстве блокчейнов, а потому их защита — это задача первостепенной важности. Можно выделить несколько распространенных уязвимостей в системах безопасности мостов, а именно слабую ончейн- и офчейн-валидацию, плохое управление нативными токенами и неправильную конфигурацию. Для обеспечения надежности алгоритма проверки необходимо тестировать мосты на предмет устойчивости ко всем видам атак.
Введение
Блокчейн-мост — это протокол, соединяющий два блокчейна и предоставляющий возможности взаимодействия между ними. Например, если у вас есть биткоины, но вы хотите работать в DeFi-сети Ethereum, то можете перевести активы с помощью моста без необходимости продавать их.
Эти протоколы стали ключом к достижению совместимости в пространстве блокчейна. Они функционируют, выполняя множество ончейн- и офчейн-валидаций, а значит, могут иметь определенные уязвимости в системе безопасности.
Важность безопасности блокчейн-мостов
Как правило, блокчейн-мосты удерживают токены, которые пользователи переводят из одного чейна в другой. По мере увеличения кроссчейн-переводов такие мосты, обычно развернутые в виде смарт-контрактов, накапливают огромное количество токенов, что подвергает их риску стать целями хакерских атак.
Кроме того, блокчейн-мосты сами по себе имеют немало уязвимых точек, поскольку включают в себя множество компонентов. Иными словами, у злоумышленников есть огромный соблазн нанести удар по таким кроссчейн-приложениям с целью хищения средств.
По оценкам CertiK, в 2022 году в результате атак на блокчейн-мосты было потеряно более 1,3 миллиарда USD, что составляет 36% от общего объема убытков за год.
Распространенные уязвимости в системах безопасности мостов
Для обеспечения безопасности мостов необходимо анализировать распространенные уязвимости и тестировать мосты на устойчивость к атакам до их запуска. Наиболее распространенные уязвимости можно разделить на четыре категории.
Слабая ончейн-валидация
На обычных блокчейн-мостах, особенно тех, что предназначены для конкретных DApp, ончейн-валидация сводится к минимуму. Эти мосты перекладывают выполнение основных операций, таких как майнинг, сжигание и перевод токенов, на централизованный внутренний сервер, тогда как все проверки осуществляются вне чейна.
Другие типы мостов подтверждают сообщения и осуществляют ончейн-валидацию при помощи смарт-контрактов. Когда пользователь выполняет ввод средств на чейн, смарт-контракт генерирует подписанное сообщение и добавляет подпись к транзакции. Эта подпись служит доказательством внесения депозита и используется для проверки запроса на вывод средств из другого чейна. Такой процесс валидации призван предотвращать любые атаки на систему безопасности, включая атаки повторного воспроизведения и подделку сведений о депозитах.
Однако, если в процессе ончейн-валидации возникает какая-либо уязвимость, злоумышленник может осуществить атаку и нанести системе серьезный ущерб. Например, если мост использует дерево Меркла для подтверждения данных транзакции, то злоумышленник может подделать доказательства. Иными словами, когда в процессе валидации обнаруживаются уязвимости, у хакеров появляется возможность обойти валидацию, создать новые токены и отправить их на свой аккаунт.
Некоторые мосты используют концепцию wrapped-токенов. Предположим, пользователь переводит DAI с Ethereum на BNB Chain. Его токены DAI выводятся из контракта Ethereum, при этом эквивалентное количество wrapped-DAI выпускается на BNB Chain.
Но если транзакция не прошла валидацию должным образом, злоумышленник может воспользоваться этим, развернув вредоносный контракт и направив wrapped-токены с моста на нужный ему адрес.
Помимо этого, хакерам необходимо одобрение жертвы на перевод активов через контракт моста с помощью функции «transferFrom» и их вывода из контракта.
Проблема усугубляется еще и тем, что многие мосты требуют от пользователей DApp постоянного одобрения токенов. Такая практика довольно распространена, так как позволяет снизить размер платы за газ. Однако вместе с тем она создает дополнительные риски, позволяя смарт-контрактам получать доступ к неограниченному количеству токенов в кошельке пользователя. Злоумышленники могут воспользоваться отсутствием валидации и необходимостью одобрения каждой транзакции, чтобы похитить токены пользователей.
Слабая офчейн-валидация
В системах некоторых мостов проверку отправленных из блокчейна сообщений выполняет внутренний офчейн-сервер. Нас прежде всего интересует проверка транзакций с депозитами.
Блокчейн-мосты с офчейн-валидацией работают следующим образом:
Пользователи используют DApp для депонирования токенов в смарт-контракт на исходном чейне.
Затем DApp отправляет хеш транзакции с депозитом на внутренний сервер через API.
Сервер несколько раз проверяет полученный хеш. Если подпись признана легитимной, то подписывающая сторона добавляет подпись к сообщению и отправляет его обратно в пользовательский интерфейс через API.
DApp проверяет полученную подпись и разрешает пользователю вывести свои токены из целевого чейна.
Задача внутреннего сервера — убедиться, что обрабатываемая транзакция с депозитом действительно имела место и не была подделана. Сервер определяет, может ли пользователь вывести токены из целевого чейна и рискует ли он стать целью злоумышленников.
Внутренний сервер должен проверить структуру транзакции, а также адрес контракта, который ее инициировал. Если пренебречь этой проверкой, то у злоумышленника появится возможность развернуть вредоносный контракт для подделки депозитной операции с той же структурой, что и у оригинальной транзакции.
Если внутренний сервер не проверит, какой адрес запустил операцию, он будет считать ее действительной по умолчанию и подпишет сообщение. Тогда злоумышленник сможет отправить хеш транзакции на внутренний сервер, обойти проверку и похитить токены из целевого чейна.
Плохое управление нативными-токенами
Мосты используют разные подходы к работе с нативными и utility-токенами. Например, нативный токен сети Ethereum — это ETH, а большинство utility-токенов создаются на основе стандарта ERC-20.
Если пользователь хочет перевести свой ETH в другой чейн, он должен сначала внести его в контракт моста. Для этого нужно просто прикрепить ETH к транзакции, а количество отправленных ETH можно будет проверить в поле транзакции «msg.value».
Депонирование токенов ERC-20 существенно отличается от депонирования ETH. Перед внесением ERC-20 пользователь должен сначала разрешить контракту моста потратить свои токены. Получив одобрение и приняв токены, контракт моста либо сожжет токены пользователя с помощью функции «burnFrom()», либо переведет их в контракт с помощью функции «transferFrom()».
Эти действия могут осуществляться в рамках одной функции посредством оператора if-else. В ином случае создаются две отдельные функции для обработки каждого варианта. Если вы попытаетесь внести ETH с помощью функции депонирования ERC-20, то рискуете потерять свои средства.
При обработке запросов на ввод средств через ERC-20 пользователи обычно предоставляют адрес токена в качестве входных данных для функции депонирования. Это подвергает операцию значительному риску, так как во время транзакции могут выполнятся ненадежные запросы с внешних адресов. Создание белого списка для одобренных токенов — это стандартная практика, призванная снизить риски. Только внесенные в белый список адреса смогут совершать операции, что также предотвратит любые внешние запросы, поскольку команда проекта уже отфильтровала одобренные адреса.
Однако все еще могут возникнуть проблемы при обработке операций по кроссчейн-переводу нативных токенов, поскольку они не имеют адресов. Адрес из нулей (0x000...0) будет представлять нативный токен. Передача функции адреса, состоящего из нулей, может помочь обойти проверку на присутствие в белом списке даже при неправильной реализации.
Когда контракт моста активирует функцию «transferFrom» для передачи активов в контракт, внешний запрос адреса из нулей получает отказ, поскольку в нем не реализована функция «transferFrom». Однако эта транзакция все равно может быть реализована, если контракт не обработает возвращаемое значение должным образом. Тогда у злоумышленника появится возможность выполнить транзакцию без передачи токенов по контракту.
Неправильная конфигурация
В большинстве блокчейн-мостов составление белых или черных списков токенов и адресов, назначение или изменение подписывающих лиц, а также настройка других важных конфигураций — это задачи первостепенной важности. Правильная настройка всех конфигураций имеет решающее значение, поскольку любые мелочи могут привести к значительным потерям.
В истории блокчейн-индустрии уже произошел случай, когда злоумышленники смогли успешно обойти проверку данных о передаче активов из-за неправильной конфигурации. За несколько дней до взлома команда проекта провела обновление протокола, которое заключалось в изменении одной переменной. Переменная представляла стандартное значение одобренного сообщения. Это изменение привело к тому, что все сообщения автоматически считались проверенными, что и позволило злоумышленникам отправить произвольное сообщение и пройти проверку.
Усиление безопасности мостов
Четыре распространенные уязвимости, описанные выше, отражают проблемы безопасности во взаимосвязанной экосистеме блокчейнов. Не существует одного универсального решения всех проблем: каждая из этих уязвимостей требует уникального подхода.
Так, довольно сложно предложить общий список рекомендаций по устранению ошибок в процессе валидации, так как у каждого моста разные требования к проверке. Наилучшим советом будет тестирование мостов на предмет уязвимости ко всем видам атак и обеспечение надежности процесса проверки.
В заключение можно сказать, что крайне важно проводить тщательную проверку на предмет потенциальных угроз и уделять особое внимание наиболее распространенным уязвимостям в системах безопасности мостов.
Заключение
Кроссчейн-мосты удерживают огромное количество активов, а потому могут стать мишенью для хакеров и злоумышленников. Разработчики должны укреплять безопасность посредством тщательного тестирования своих мостов перед развертыванием, а также привлекать к аудиту сторонние организации с целью защиты от взломов и атак. Мосты играют огромное значение в пространстве блокчейнов, и безопасность должна быть приоритетом первой значимости при проектировании и создании эффективной инфраструктуры Web3.
Рекомендуемая литература
Что такое мосты между блокчейнами
Что такое кроссчейн-совместимость
Три популярных криптовалютных моста и принципы их работы
Предупреждение о рисках и отказ от ответственности: следующие материалы предоставляются на условиях «как есть» без каких-либо гарантий исключительно для общих справочных и образовательных целей. Эта информация не должна рассматриваться как финансовая, юридическая консультация или рекомендация по приобретению какого-либо конкретного продукта или услуги. Вам следует самостоятельно обратиться за советом к соответствующим профессиональным консультантам. Поскольку статья написана сторонним автором, обратите внимание, что высказанные мнения принадлежат стороннему автору и необязательно отражают точку зрения Binance Academy. Для получения более подробной информации перейдите по ссылке. Стоимость цифровых активов может быть волатильной. Стоимость инвестированных средств может увеличиваться и уменьшаться. Вы можете не вернуть инвестированные средства. Вы несете полную ответственность за свои инвестиционные решения. Binance Academy не несет ответственность за ваши возможные убытки. Данная информация не является финансовой, юридической или профессиональной рекомендацией. Чтобы узнать больше, ознакомьтесь с нашими Условиями использования и Предупреждением о рисках.