Анализ атаки повторного входа на Jarvis Network с использованием Срочные займы

Недавно проект под названием Jarvis_Network подвергся атаке реинжекции срочных займов, в результате чего было потеряно около 663000 токенов 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