Аналіз атаки повторного входу на термінові позики проекту Jarvis Network
15 січня 2023 року проект Jarvis_Network зазнав атаки, в результаті якої було вкрадено 663,101 MATIC. Ця подія викликала занепокоєння щодо безпеки проекту.
Аналізуючи стек викликів транзакцій, було виявлено, що зловмисник скористався вразливістю повторного входу. Під час повторного входу, для одного й того ж виклику функції одного й того ж контракту, хоча вхідні параметри однакові, значення повернення мають істотні відмінності. Ці відмінності в основному виникають у функції remove_liquidity.
Атака повторного входу в основному націлена на функцію remove_liquidity певного смарт-контракту. Ця функція повертає токени, які користувач додав, під час видалення ліквідності. Через гомоморфізм Polygon та EVM-ланцюгів, під час переказу MATIC на контракт спрацьовує логіка повторного входу.
Додатковий аналіз показав, що проблема полягає в реалізації функції getUnderlyingPrice. Ця функція пов'язана з кількома закритими контрактами, що ускладнює аналіз. Однак, перевіряючи слоти пам'яті та стек викликів, ми можемо зробити висновки про значення ключових змінних і шлях викликів функцій.
Суть атаки полягає в тому, що значення, яке повертає функція get_virtual_price, зазнало суттєвих змін до і після повторного входу. Ця зміна пов'язана з часом оновлення змінної self.D. У нормальних умовах self.D має оновлюватися після завершення переказу, але під час цієї атаки, через повторний вхід, виникли помилки в розрахунку ціни.
Процес виконання функції remove_liquidity включає: 1) знищення LP-токенів користувача; 2) надсилання заставлених коштів користувачу; 3) оновлення self.D значення. Атакуючий виконує повторний вхід на другому етапі, використовуючи не своєчасно оновлене self.D значення для позики, внаслідок чого отримує неправомірну вигоду.
Варто зазначити, що хоча функція remove_liquidity використовує декоратор @nonreentrant('lock') для запобігання повторним викликам, через те, що зловмисник після повторного виклику потрапляє в інший контракт для позики, цей замок на повторний виклик не справив очікуваного ефекту.
Цей напад виявив важливість моменту оновлення змінних у смарт-контрактах. Для підвищення безпеки рекомендується, щоб проектна команда вжила такі заходи:
Провести суворий аудит безпеки
Переконайтеся, що зміни змінних завершено до зовнішнього виклику
Використання методу отримання інформації про ціни з різних джерел даних
Дотримуйтесь моделі "Перевірки-Ефекти-Взаємодії" (Checks-Effects-Interactions) при написанні коду
Завдяки впровадженню цих найкращих практик можна суттєво підвищити безпеку та стабільність смарт-контрактів, забезпечуючи більш надійну інфраструктуру для екосистеми Web3.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Jarvis Network зазнав атаки повторного входу через Термінові позики, 663,101 MATIC було вкрадено
Аналіз атаки повторного входу на термінові позики проекту Jarvis Network
15 січня 2023 року проект Jarvis_Network зазнав атаки, в результаті якої було вкрадено 663,101 MATIC. Ця подія викликала занепокоєння щодо безпеки проекту.
Аналізуючи стек викликів транзакцій, було виявлено, що зловмисник скористався вразливістю повторного входу. Під час повторного входу, для одного й того ж виклику функції одного й того ж контракту, хоча вхідні параметри однакові, значення повернення мають істотні відмінності. Ці відмінності в основному виникають у функції remove_liquidity.
Атака повторного входу в основному націлена на функцію remove_liquidity певного смарт-контракту. Ця функція повертає токени, які користувач додав, під час видалення ліквідності. Через гомоморфізм Polygon та EVM-ланцюгів, під час переказу MATIC на контракт спрацьовує логіка повторного входу.
Додатковий аналіз показав, що проблема полягає в реалізації функції getUnderlyingPrice. Ця функція пов'язана з кількома закритими контрактами, що ускладнює аналіз. Однак, перевіряючи слоти пам'яті та стек викликів, ми можемо зробити висновки про значення ключових змінних і шлях викликів функцій.
! Аналіз інциденту атаки повторного входу в флеш-позику Jarvis Network
Суть атаки полягає в тому, що значення, яке повертає функція get_virtual_price, зазнало суттєвих змін до і після повторного входу. Ця зміна пов'язана з часом оновлення змінної self.D. У нормальних умовах self.D має оновлюватися після завершення переказу, але під час цієї атаки, через повторний вхід, виникли помилки в розрахунку ціни.
Процес виконання функції remove_liquidity включає: 1) знищення LP-токенів користувача; 2) надсилання заставлених коштів користувачу; 3) оновлення self.D значення. Атакуючий виконує повторний вхід на другому етапі, використовуючи не своєчасно оновлене self.D значення для позики, внаслідок чого отримує неправомірну вигоду.
Варто зазначити, що хоча функція remove_liquidity використовує декоратор @nonreentrant('lock') для запобігання повторним викликам, через те, що зловмисник після повторного виклику потрапляє в інший контракт для позики, цей замок на повторний виклик не справив очікуваного ефекту.
! Аналіз інцидентів атаки повторного входу флеш-позики Jarvis Network
Цей напад виявив важливість моменту оновлення змінних у смарт-контрактах. Для підвищення безпеки рекомендується, щоб проектна команда вжила такі заходи:
Завдяки впровадженню цих найкращих практик можна суттєво підвищити безпеку та стабільність смарт-контрактів, забезпечуючи більш надійну інфраструктуру для екосистеми Web3.