Кросс-чейн Протокол столкнулся с уязвимостью безопасности: глубокий анализ
Недавно один кросс-чейн протокол столкнулся с серьезной уязвимостью безопасности, что вызвало широкий интерес в отрасли. Команда специалистов по безопасности провела детальный анализ этого инцидента, выявив, как злоумышленники использовали уязвимость контракта для получения доступа и в конечном итоге осуществили атаку.
Принцип атаки
Анализ показывает, что основная проблема атаки заключается в уязвимости одного из ключевых функций контракта в протоколе. Злоумышленники, используя тщательно подготовленные данные, успешно изменили адрес администратора в другом важном контракте, получив контроль над средствами. Это противоречит ранее распространенной версии о泄露 приватного ключа администратора.
Детали атаки
Злоумышленник использовал функцию под названием verifyHeaderAndExecuteTx, которая может выполнять кросс-чейн транзакции.
Из-за отношений собственности между контрактами, злоумышленник может вызвать функцию putCurEpochConPubKeyBytes другого контракта через вышеупомянутое вызов функции, изменив ключевую роль хранителя.
Атакующий создал специфические данные транзакции, что привело к косвенному вызову функции putCurEpochConPubKeyBytes через функцию verifyHeaderAndExecuteTx, изменив роль хранителя на адрес, контролируемый атакующим.
После завершения замены роли keeper, атакующий может произвольно конструировать транзакции и извлекать любое количество средств из контракта.
Процесс атаки
Атакующий сначала инициирует атаку в одной из блокчейн-сетей, изменяя адрес хранителя с помощью тщательно спроектированных транзакций. Затем атакующий последовательно проводит несколько транзакций, извлекая крупные суммы из атакованного контракта.
После завершения атаки, из-за изменения keeper, нормальные сделки других пользователей были отклонены.
Стоит отметить, что злоумышленники использовали аналогичный метод для осуществления атаки на другой мейнстримный кросс-чейн, что показывает, что это была преднамеренная атака.
!
Резюме
Коренная причина этой атаки заключается в уязвимостях, существующих в дизайне Протокола. Атакующий ловко воспользовался отношениями вызова между контрактами и настройками прав доступа, успешно изменив ключевой адрес keeper, создав специальные данные транзакции. Это открытие исправило прежние ошибочные предположения о утечке приватного ключа и предоставило важные рекомендации для безопасного дизайна аналогичных Протоколов.
Это событие снова подчеркивает вызовы, с которыми сталкиваются протоколы децентрализованных финансов в области безопасности, и напоминает разработчикам о необходимости быть более осторожными при проектировании функций кросс-чейн взаимодействия, тщательно учитывая различные возможные сценарии атак.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
16 Лайков
Награда
16
5
Поделиться
комментарий
0/400
BuyHighSellLow
· 32м назад
Неприемлемо, опять убытки. Если бы я проверил контракт, ничего бы не случилось.
Посмотреть ОригиналОтветить0
MetaReckt
· 07-19 15:28
Тс-тс, код контракта еще не достаточно тщательно проверен.
Посмотреть ОригиналОтветить0
zkProofInThePudding
· 07-19 15:27
Еще одна брешь в смарт-контрактах была вскрыта
Посмотреть ОригиналОтветить0
screenshot_gains
· 07-19 15:21
Это так легко, что меня так чернили.
Посмотреть ОригиналОтветить0
GateUser-aa7df71e
· 07-19 15:18
Ай-яй-яй, с кросс-чейн снова что-то случилось, как эти проекты могут каждый день подвергаться Клиповые купоны.
Анализ уязвимостей безопасности кросс-чейн протоколов: как злоумышленники могут изменить keeper для получения контроля над финансами
Кросс-чейн Протокол столкнулся с уязвимостью безопасности: глубокий анализ
Недавно один кросс-чейн протокол столкнулся с серьезной уязвимостью безопасности, что вызвало широкий интерес в отрасли. Команда специалистов по безопасности провела детальный анализ этого инцидента, выявив, как злоумышленники использовали уязвимость контракта для получения доступа и в конечном итоге осуществили атаку.
Принцип атаки
Анализ показывает, что основная проблема атаки заключается в уязвимости одного из ключевых функций контракта в протоколе. Злоумышленники, используя тщательно подготовленные данные, успешно изменили адрес администратора в другом важном контракте, получив контроль над средствами. Это противоречит ранее распространенной версии о泄露 приватного ключа администратора.
Детали атаки
Злоумышленник использовал функцию под названием verifyHeaderAndExecuteTx, которая может выполнять кросс-чейн транзакции.
Из-за отношений собственности между контрактами, злоумышленник может вызвать функцию putCurEpochConPubKeyBytes другого контракта через вышеупомянутое вызов функции, изменив ключевую роль хранителя.
Атакующий создал специфические данные транзакции, что привело к косвенному вызову функции putCurEpochConPubKeyBytes через функцию verifyHeaderAndExecuteTx, изменив роль хранителя на адрес, контролируемый атакующим.
После завершения замены роли keeper, атакующий может произвольно конструировать транзакции и извлекать любое количество средств из контракта.
Процесс атаки
Атакующий сначала инициирует атаку в одной из блокчейн-сетей, изменяя адрес хранителя с помощью тщательно спроектированных транзакций. Затем атакующий последовательно проводит несколько транзакций, извлекая крупные суммы из атакованного контракта.
После завершения атаки, из-за изменения keeper, нормальные сделки других пользователей были отклонены.
Стоит отметить, что злоумышленники использовали аналогичный метод для осуществления атаки на другой мейнстримный кросс-чейн, что показывает, что это была преднамеренная атака.
!
Резюме
Коренная причина этой атаки заключается в уязвимостях, существующих в дизайне Протокола. Атакующий ловко воспользовался отношениями вызова между контрактами и настройками прав доступа, успешно изменив ключевой адрес keeper, создав специальные данные транзакции. Это открытие исправило прежние ошибочные предположения о утечке приватного ключа и предоставило важные рекомендации для безопасного дизайна аналогичных Протоколов.
Это событие снова подчеркивает вызовы, с которыми сталкиваются протоколы децентрализованных финансов в области безопасности, и напоминает разработчикам о необходимости быть более осторожными при проектировании функций кросс-чейн взаимодействия, тщательно учитывая различные возможные сценарии атак.