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