Анализ атаки повторного входа на проект 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)

Для повышения безопасности, команде проекта следует:

• Проведение строгого аудита безопасности
• Переменные следует изменять перед внешним вызовом
• Использование нескольких источников данных для получения цен
• Соблюдайте кодовый стандарт "сначала оцените, затем запишите в переменную, а затем выполните внешний вызов".

С помощью этих мер можно значительно повысить безопасность и стабильность проекта, эффективно предотвращая подобные атаки.