Poly Network зазнав атаки хакера, який умілого використав вразливість контракту для зміни keeper

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

Аналіз інциденту з атакою на Poly Network: деталі виявляють, як зловмисник хитро використав вразливість контракту

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

Ключові точки атаки

  1. Атака полягає в тому, що функція verifyHeaderAndExecuteTx контракту EthCrossChainManager може виконувати крос-чейн транзакції через функцію _executeCrossChainTx.

  2. Власник контракту EthCrossChainData є контракт EthCrossChainManager, який може викликати функцію putCurEpochConPubKeyBytes першого для зміни keeper.

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

  4. Після завершення заміни адреси keeper, зловмисник може вільно створювати транзакції для вилучення коштів з контракту.

Відновлення процесу атаки

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

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

  3. Після завершення атаки, через те, що keeper був змінений, нормальні транзакції інших користувачів були скасовані.

  4. Подібні методи атаки також реалізовані в мережі Ethereum.

!

Підсумок події

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

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

Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • 3
  • Поділіться
Прокоментувати
0/400
notSatoshi1971vip
· 18год тому
Код можна зрозуміти, але не розумію, чому так тупо написано.
Переглянути оригіналвідповісти на0
AirdropHunterKingvip
· 18год тому
І знову не закриваючи контракт, і про мене про обікрали, просто жорстко натрапивши на вразливість
Переглянути оригіналвідповісти на0
LightningClickervip
· 18год тому
Вразливість занадто очевидна, чи не так? Як можна запустити, навіть не подивившись?
Переглянути оригіналвідповісти на0
  • Закріпити