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

Нещодавно проект під назвою Jarvis_Network зазнав термінового позики повторного нападу, що призвело до втрат приблизно 663 тисяч токенів MATIC. Ця подія сталася ввечері 15 січня 2023 року.

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

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

Подальше розслідування виявило, що зловмисники під час видалення ліквідності скористалися вразливістю в моменті оновлення змінної self.D. У нормальних умовах процес методу remove_liquidity має бути таким: 1) знищити LP користувача; 2) надіслати заставні кошти користувачу; 3) оновити self.D. Однак зловмисники виконали повторний вхід на другому етапі, що призвело до серйозних помилок у розрахунку ціни.

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

Ця атака в основному виявила дві проблеми:

1. Логіка зміни змінної знаходиться після зовнішнього виклику, що призводить до аномалії отримання ціни.
2. Крос-контрактний повторний вхід робить замок повторного входу неефективним.

Щоб запобігти подібним атакам, рекомендується, щоб проектна команда вжила наступні заходи:

1. Переконайтеся, що код пройшов суворий аудит безпеки.
2. Перемістіть зміни змінних перед зовнішнім викликом.
3. Використання кількох джерел даних для отримання цін.
4. Дотримуйтесь кодувального стандарту "спочатку перевіряйте, потім записуйте у змінну, а потім викликайте зовнішні функції" (Checks-Effects-Interactions).

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

! Аналіз інцидентів атаки повторного входу флеш-позики Jarvis Network