Аналіз атаки повторного входу на проект Jarvis Network за допомогою Термінових позик

Дані показують, що 15 січня 2023 року о 17:43:37 UTC проект Jarvis_Network зазнав атаки, в результаті якої було втрачено 663,101 MATIC.

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

• Перед повторним входом: 1,002,157,321,772,769,944
• Після повторного входу: 10,091,002,696,492,234,934

Повторний вхід відбувається у функції remove_liquidity. Ця функція повертає токени, додані користувачем, під час видалення ліквідності. Оскільки Polygon та EVM є гомоморфними ланцюгами, під час переказу MATIC на контракт буде викликаний повторний вхід контракту.

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

Повернене значення функції get_virtual_price залежить від змінної self.D. У функції remove_liquidity оновлення self.D відбувається після переказу токенів. Зловмисник, видаляючи ліквідність, передає MATIC на атакуючий контракт, а під час виклику fallback спочатку запитує ціну токена. Оскільки self.D ще не оновлено, це призводить до помилки у отриманні ціни.

процес функції remove_liquidity:

1. Знищення LP користувача
2. Відправка коштів користувача на заставу
3. Оновити self.D

Атакуючий на другому етапі виконав повторний виклик, використовуючи неоновлений self.D значення для отримання позики, отримавши 10 разів більше коштів, ніж за нормальною ціною.

Хоча функція remove_liquidity використовує @nonreentrant('lock') для запобігання повторним викликам, зловмисники обійшли цей захист через крос-контрактний повторний виклик.

Цей напад виявив кілька ключових проблем:

1. Логіка зміни змінних після зовнішнього виклику призвела до аномалії отримання ціни
2. Крос-контрактний повторний вхід робить замок повторного входу недійсним
3. Не дотримувались моделі "Перевірки-Ефекти-Взаємодії" (Checks-Effects-Interactions)

Для підвищення безпеки команда проекту повинна:

• Провести суворий аудит безпеки
• Помістіть зміни змінних перед зовнішнім викликом
• Використання кількох джерел даних для отримання цін
• Дотримуйтесь стандарту кодування "спочатку оцініть, потім запишіть у змінну, а потім викликайте зовнішні функції".

Завдяки цим заходам можна значно підвищити безпеку та стабільність проекту, ефективно запобігти подібним атакам.