крос-ланцюг протокол контракту вразливість піддалася Хакер атаці Безпека дизайн знову б'є на сполох

robot
Генерація анотацій у процесі

Крос-ланцюг протокол вразливість призвела до重大安全事件

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

Атака на ядро

Ключ атаки полягає в функції verifyHeaderAndExecuteTx контракту EthCrossChainManager. Ця функція може виконувати конкретні крос-ланцюгові транзакції через функцію _executeCrossChainTx. Оскільки власник контракту EthCrossChainData є контракт EthCrossChainManager, останній може викликати функцію putCurEpochConPubKeyBytes першого, щоб змінити keeper контракту.

Зловмисник, передаючи ретельно розроблені дані в функцію verifyHeaderAndExecuteTx, активував виконання функції _executeCrossChainTx, що викликає функцію putCurEpochConPubKeyBytes контракту EthCrossChainData, змінюючи роль keeper на адресу, вказану зловмисником. Завершивши цей етап, зловмисник може створити транзакцію, щоб вилучити будь-яку кількість коштів з контракту.

Процес атаки

  1. Зловмисник спочатку через функцію verifyHeaderAndExecuteTx контракту EthCrossChainManager викликав функцію putCurEpochConPubKeyBytes, змінивши keeper.

  2. Після цього зловмисник почав здійснювати ряд атакуючих транзакцій, щоб витягнути кошти з контракту.

  3. Через зміни в keeper інші користувачі не можуть виконати свої звичайні транзакції.

  4. Схожі методи атаки також були реалізовані в мережі ефіріум, процес приблизно однаковий.

!

Прозорливість подій

Ця подія виявила важливу вразливість у дизайні смарт-контрактів. Keeper контракту EthCrossChainData може бути змінений контрактом EthCrossChainManager, а функція verifyHeaderAndExecuteTx останнього може виконувати введені користувачем дані. Такий дизайн надає можливість для атакуючих.

Ця атака не була викликана витоком приватного ключа keeper, а є наслідком вразливості в дизайні контракту. Це нагадує нам про те, що при проєктуванні крос-ланцюгових протоколів необхідно більш уважно розглядати управління правами та механізми верифікації даних, щоб запобігти повторенню подібних інцидентів безпеки.

Для всього сектору крос-ланцюгів ця подія ще раз підкреслила важливість безпекового аудиту. Навіть найбільш досконалі протоколи можуть мати недоглянуті вразливості. Постійна перевірка безпеки та виправлення вразливостей є надзвичайно важливими для забезпечення безпеки активів користувачів.

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 4
  • Поділіться
Прокоментувати
0/400
SundayDegenvip
· 07-14 15:39
Все ж треба додати нульовий захист.
Переглянути оригіналвідповісти на0
GasGrillMastervip
· 07-14 15:36
Знову трапилася проблема, втекли, втекли.
Переглянути оригіналвідповісти на0
RooftopVIPvip
· 07-14 15:29
Знову потрібно показати сонце на даху.
Переглянути оригіналвідповісти на0
TokenCreatorOPvip
· 07-14 15:22
класичні дії...невдахи обдурювати людей, як лохів
Переглянути оригіналвідповісти на0
  • Закріпити