Крос-ланцюг протокол зазнав безпекової вразливості: глибокий аналіз
Нещодавно, крос-ланцюгова взаємодійна протокол зазнав серйозної уразливості безпеки, що викликало широкий інтерес у галузі. Команда експертів з безпеки провела детальний аналіз цього інциденту, виявивши, як зловмисники використали уразливість контракту для отримання доступу і врешті-решт здійснення атаки.
Принцип атаки
Аналіз показує, що основа атаки полягає у вразливості одного з ключових функцій контракту в протоколі. Атакувальник, за допомогою ретельно сконструйованих даних, успішно змінив адресу адміністратора в іншому важливому контракті, отримавши контроль над коштами. Це не відповідає раніше поширеній версії про витік приватного ключа адміністратора.
Деталі атаки
Зловмисник скористався функцією, яка називається verifyHeaderAndExecuteTx, що може виконувати крос-ланцюг交易.
Внаслідок відносин власності між контрактами, зловмисник може викликати функцію putCurEpochConPubKeyBytes іншого контракту через вищезгадану функцію, таким чином змінюючи ключову роль keeper.
Атакуючий сконструював специфічні дані транзакції, що призвело до непрямого виклику функції putCurEpochConPubKeyBytes через функцію verifyHeaderAndExecuteTx, змінюючи роль keeper на адресу, контрольовану атакуючим.
Завершивши заміну ролі keeper, зловмисник може вільно конструювати транзакції, витягуючи будь-яку кількість коштів з контракту.
Процес атаки
Атакуюча сторона спочатку розпочинає атаку на один з крос-ланцюгів, шляхом ретельно спланованих транзакцій змінює адресу keeper. Потім атакуюча сторона безперервно здійснює кілька транзакцій, щоб витягти велику суму коштів з атакованого контракту.
Після завершення атаки, через зміну keeper, нормальні транзакції інших користувачів були відхилені.
Варто зазначити, що зловмисники використали подібний підхід для здійснення атаки на іншій основній мережі блокчейн, що свідчить про те, що це була спланована, крос-ланцюгова атака.
!
Підсумок
Корінна причина цієї атаки полягає у вразливостях, що існують у дизайні протоколу. Зловмисник хитро використав відносини виклику між контрактами та налаштування прав доступу, успішно змінивши ключову адресу keeper, створивши спеціальні дані транзакції. Це відкриття виправило попередні неправильні припущення щодо витоку приватного ключа і надало важливі рекомендації для безпечного дизайну аналогічних протоколів.
Ця подія ще раз підкреслила виклики, з якими стикаються протоколи децентралізованих фінансів у питанні безпеки, а також нагадала розробникам про необхідність бути більш обережними при проектуванні функцій крос-ланцюга та ретельно враховувати різні можливі сценарії атак.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
16 лайків
Нагородити
16
5
Поділіться
Прокоментувати
0/400
BuyHighSellLow
· 07-21 18:25
Неприпустимо, знову втратив. Якби я прийшов перевірити контракт, нічого б не сталося.
Переглянути оригіналвідповісти на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 іншого контракту через вищезгадану функцію, таким чином змінюючи ключову роль keeper.
Атакуючий сконструював специфічні дані транзакції, що призвело до непрямого виклику функції putCurEpochConPubKeyBytes через функцію verifyHeaderAndExecuteTx, змінюючи роль keeper на адресу, контрольовану атакуючим.
Завершивши заміну ролі keeper, зловмисник може вільно конструювати транзакції, витягуючи будь-яку кількість коштів з контракту.
Процес атаки
Атакуюча сторона спочатку розпочинає атаку на один з крос-ланцюгів, шляхом ретельно спланованих транзакцій змінює адресу keeper. Потім атакуюча сторона безперервно здійснює кілька транзакцій, щоб витягти велику суму коштів з атакованого контракту.
Після завершення атаки, через зміну keeper, нормальні транзакції інших користувачів були відхилені.
Варто зазначити, що зловмисники використали подібний підхід для здійснення атаки на іншій основній мережі блокчейн, що свідчить про те, що це була спланована, крос-ланцюгова атака.
!
Підсумок
Корінна причина цієї атаки полягає у вразливостях, що існують у дизайні протоколу. Зловмисник хитро використав відносини виклику між контрактами та налаштування прав доступу, успішно змінивши ключову адресу keeper, створивши спеціальні дані транзакції. Це відкриття виправило попередні неправильні припущення щодо витоку приватного ключа і надало важливі рекомендації для безпечного дизайну аналогічних протоколів.
Ця подія ще раз підкреслила виклики, з якими стикаються протоколи децентралізованих фінансів у питанні безпеки, а також нагадала розробникам про необхідність бути більш обережними при проектуванні функцій крос-ланцюга та ретельно враховувати різні можливі сценарії атак.