Аналіз атаки повторного входу на термінові позики проекту Jarvis Network
15 січня 2023 року проект Jarvis_Network зазнав атаки, внаслідок чого було втрачено 663,101 MATIC. Провівши аналіз стеку викликів атакуючих транзакцій, було виявлено наявність логіки повторного входу. Під час повторного входу для одного й того ж виклику функції одного й того ж контракту параметри були однаковими, але значення, що повертаються, суттєво відрізнялися.
Повторний вхід відбувається у функції remove_liquidity. Ця функція повертає токени, додані користувачем, під час видалення ліквідності. Оскільки Polygon є EVM-сумісним, переказ MATIC на контракт викликає повторний вхід.
Глибокий аналіз показав, що проблема полягає в реалізації функції getUnderlyingPrice. Ця функція передбачає кілька викликів контрактів, які в кінцевому підсумку впливають на значення, що повертається функцією get_virtual_price. Значення, що повертається функцією get_virtual_price, залежить від змінної self.D, а оновлення self.D відбувається після переказу.
Атакуючий, видаляючи ліквідність, після перенесення MATIC до атакуючого контракту, викликає функцію fallback для запиту ціни. Оскільки оновлення self.D відбувається після переказу, це призводить до помилки в отриманні попередньої ціни. Процес видалення ліквідності виглядає так: 1) знищити LP користувача; 2) надіслати кошти, що були заблоковані користувачем; 3) оновити self.D.
self.D використовується для розрахунку ціни, також буде оновлюватися при додаванні ліквідності. Кошти ліквідності зловмисника значно більші, у нормальних умовах значення self.D буде набагато меншим. Але зловмисник у кроці 2 здійснює повторний вхід і позичає за ціною, що в 10 разів перевищує початкову ціну. Це пов'язано з тим, що значення self.D зростає під час додавання ліквідності, а при видаленні ліквідності не оновлюється вчасно.
Хоча метод remove_liquidity використовує @nonreentrant('lock') для запобігання повторному входу, зловмисник може повторно увійти в інші контракти для позикових коштів, що робить замок повторного входу неефективним.
Основною причиною цієї атаки є зміна логіки модифікації змінних після зовнішнього виклику, що призвело до аномалії отримання ціни. Повторний вхід через контракти зробив замок для повторного входу недієздатним. Рекомендується проектній команді провести суворий аудит безпеки, розмістивши модифікацію змінних перед зовнішніми викликами, використовуючи спосіб отримання цін з кількох джерел. Дотримання кодувальної норми "спочатку перевірити, потім записати змінну, а потім виконати зовнішній виклик" (Checks-Effects-Interactions) може підвищити безпеку та стабільність проекту.
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
9 лайків
Нагородити
9
5
Поділіться
Прокоментувати
0/400
HalfBuddhaMoney
· 08-02 05:37
Не можу стільки отримати...
Переглянути оригіналвідповісти на0
ZeroRushCaptain
· 08-02 05:37
Ще один загинув, всі заощадження пропали в нікуди. Втрачаємо гроші, Сем Альтман, вперед!
Переглянути оригіналвідповісти на0
ForkLibertarian
· 08-02 05:29
Рука так повільно рухається, що вже пізно для Скорочення втрат та Шахрайства.
Переглянути оригіналвідповісти на0
StakeTillRetire
· 08-02 05:24
Ще одна трагедія з повторним входом, замикаюся.
Переглянути оригіналвідповісти на0
SighingCashier
· 08-02 05:13
Знову програли, знову вразливість повторного входу.
Jarvis Network зазнав термінової позики повторного нападу, втративши 663,101 MATIC
Аналіз атаки повторного входу на термінові позики проекту Jarvis Network
15 січня 2023 року проект Jarvis_Network зазнав атаки, внаслідок чого було втрачено 663,101 MATIC. Провівши аналіз стеку викликів атакуючих транзакцій, було виявлено наявність логіки повторного входу. Під час повторного входу для одного й того ж виклику функції одного й того ж контракту параметри були однаковими, але значення, що повертаються, суттєво відрізнялися.
Повторний вхід відбувається у функції remove_liquidity. Ця функція повертає токени, додані користувачем, під час видалення ліквідності. Оскільки Polygon є EVM-сумісним, переказ MATIC на контракт викликає повторний вхід.
Глибокий аналіз показав, що проблема полягає в реалізації функції getUnderlyingPrice. Ця функція передбачає кілька викликів контрактів, які в кінцевому підсумку впливають на значення, що повертається функцією get_virtual_price. Значення, що повертається функцією get_virtual_price, залежить від змінної self.D, а оновлення self.D відбувається після переказу.
Атакуючий, видаляючи ліквідність, після перенесення MATIC до атакуючого контракту, викликає функцію fallback для запиту ціни. Оскільки оновлення self.D відбувається після переказу, це призводить до помилки в отриманні попередньої ціни. Процес видалення ліквідності виглядає так: 1) знищити LP користувача; 2) надіслати кошти, що були заблоковані користувачем; 3) оновити self.D.
self.D використовується для розрахунку ціни, також буде оновлюватися при додаванні ліквідності. Кошти ліквідності зловмисника значно більші, у нормальних умовах значення self.D буде набагато меншим. Але зловмисник у кроці 2 здійснює повторний вхід і позичає за ціною, що в 10 разів перевищує початкову ціну. Це пов'язано з тим, що значення self.D зростає під час додавання ліквідності, а при видаленні ліквідності не оновлюється вчасно.
Хоча метод remove_liquidity використовує @nonreentrant('lock') для запобігання повторному входу, зловмисник може повторно увійти в інші контракти для позикових коштів, що робить замок повторного входу неефективним.
Основною причиною цієї атаки є зміна логіки модифікації змінних після зовнішнього виклику, що призвело до аномалії отримання ціни. Повторний вхід через контракти зробив замок для повторного входу недієздатним. Рекомендується проектній команді провести суворий аудит безпеки, розмістивши модифікацію змінних перед зовнішніми викликами, використовуючи спосіб отримання цін з кількох джерел. Дотримання кодувальної норми "спочатку перевірити, потім записати змінну, а потім виконати зовнішній виклик" (Checks-Effects-Interactions) може підвищити безпеку та стабільність проекту.
! Аналіз інцидентів атаки повторного входу в флеш-позику Jarvis Network
! Аналіз інцидентів атаки повторного входу флеш-позики Jarvis Network