Нещодавно кросчейн-протокол взаємодії Poly Network зазнав атаки хакера, що викликало широкий інтерес в індустрії. Після аналізу команда безпеки виявила, що ця атака сталася не через витік приватного ключа keeper, а завдяки хитро сконструйованим даним, зловмисник використав вразливість контракту для зміни адреси keeper у контракті EthCrossChainData.
Принцип атаки
Суть атаки полягає в тому, що функція verifyHeaderAndExecuteTx контракту EthCrossChainManager може виконувати конкретні міжланцюгові транзакції через функцію _executeCrossChainTx. Оскільки власник контракту EthCrossChainData є контрактом EthCrossChainManager, останній може викликати функцію putCurEpochConPubKeyBytes контракту EthCrossChainData, щоб змінити keeper контракту.
Зловмисник використовує функцію verifyHeaderAndExecuteTx, передаючи ретельно спроектовані дані, що призводить до виклику функції putCurEpochConPubKeyBytes контракту EthCrossChainData функцією _executeCrossChainTx, тим самим змінюючи роль keeper на адресу, вказану зловмисником. Після завершення заміни адреси keeper зловмисник може створювати транзакції і довільно витягувати будь-яку кількість коштів з контракту.
Процес атаки
Атакуючий спочатку викликає функцію putCurEpochConPubKeyBytes через функцію verifyHeaderAndExecuteTx контракту EthCrossChainManager, щоб змінити keeper.
Після зміни keeper, зловмисник почав здійснювати серію атакуючих угод, витягуючи кошти з контракту.
Після завершення атаки, через те, що keeper був змінений, нормальні транзакції інших користувачів були відхилені.
Цей режим атаки також має подібні операції в мережі Ethereum.
!
Підсумок
Ключем атаки є те, що keeper контракту EthCrossChainData може бути змінений контрактом EthCrossChainManager, а функція verifyHeaderAndExecuteTx контракту EthCrossChainManager може виконувати введені користувачем дані через функцію _executeCrossChainTx. Атакуючий скористався цим, успішно змінивши keeper контракту EthCrossChainData на адресу, контрольовану атакуючим, шляхом конструювання специфічних даних.
Ця подія ще раз нагадує нам, що при проектуванні смарт-контрактів необхідно особливо звертати увагу на управління доступом і безпеку викликів функцій. Для функцій, які можуть впливати на ключові параметри, слід впроваджувати більш суворий контроль доступу та механізми безпеки. Водночас безпеці крос-чейн проектів також слід приділити більше уваги, оскільки вони часто залучають великі кошти та складну логіку взаємодії.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
21 лайків
Нагородити
21
3
Поділіться
Прокоментувати
0/400
GasFeeCrier
· 07-11 15:43
Знову бачимо, як смартконтракти провалюються. Це ж просто жах!
Переглянути оригіналвідповісти на0
SleepTrader
· 07-11 02:54
Ще один випадок мудрості заднім числом безпеки аудиту
Poly Network зазнав нападу: вразливість смартконтракту призвела до зміни keeper
Аналіз інциденту атаки на Poly Network
Нещодавно кросчейн-протокол взаємодії Poly Network зазнав атаки хакера, що викликало широкий інтерес в індустрії. Після аналізу команда безпеки виявила, що ця атака сталася не через витік приватного ключа keeper, а завдяки хитро сконструйованим даним, зловмисник використав вразливість контракту для зміни адреси keeper у контракті EthCrossChainData.
Принцип атаки
Суть атаки полягає в тому, що функція verifyHeaderAndExecuteTx контракту EthCrossChainManager може виконувати конкретні міжланцюгові транзакції через функцію _executeCrossChainTx. Оскільки власник контракту EthCrossChainData є контрактом EthCrossChainManager, останній може викликати функцію putCurEpochConPubKeyBytes контракту EthCrossChainData, щоб змінити keeper контракту.
Зловмисник використовує функцію verifyHeaderAndExecuteTx, передаючи ретельно спроектовані дані, що призводить до виклику функції putCurEpochConPubKeyBytes контракту EthCrossChainData функцією _executeCrossChainTx, тим самим змінюючи роль keeper на адресу, вказану зловмисником. Після завершення заміни адреси keeper зловмисник може створювати транзакції і довільно витягувати будь-яку кількість коштів з контракту.
Процес атаки
Атакуючий спочатку викликає функцію putCurEpochConPubKeyBytes через функцію verifyHeaderAndExecuteTx контракту EthCrossChainManager, щоб змінити keeper.
Після зміни keeper, зловмисник почав здійснювати серію атакуючих угод, витягуючи кошти з контракту.
Після завершення атаки, через те, що keeper був змінений, нормальні транзакції інших користувачів були відхилені.
Цей режим атаки також має подібні операції в мережі Ethereum.
!
Підсумок
Ключем атаки є те, що keeper контракту EthCrossChainData може бути змінений контрактом EthCrossChainManager, а функція verifyHeaderAndExecuteTx контракту EthCrossChainManager може виконувати введені користувачем дані через функцію _executeCrossChainTx. Атакуючий скористався цим, успішно змінивши keeper контракту EthCrossChainData на адресу, контрольовану атакуючим, шляхом конструювання специфічних даних.
Ця подія ще раз нагадує нам, що при проектуванні смарт-контрактів необхідно особливо звертати увагу на управління доступом і безпеку викликів функцій. Для функцій, які можуть впливати на ключові параметри, слід впроваджувати більш суворий контроль доступу та механізми безпеки. Водночас безпеці крос-чейн проектів також слід приділити більше уваги, оскільки вони часто залучають великі кошти та складну логіку взаємодії.