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

15 января 2023 года проект Jarvis_Network подвергся атаке, в результате которой было украдено 663,101 MATIC. Этот инцидент вызвал беспокойство по поводу безопасности проекта.

Анализируя стек вызовов транзакций, было выяснено, что злоумышленник использовал уязвимость повторного входа. В процессе повторного входа, при вызове одной и той же функции одного и того же контракта, хотя входные параметры одинаковы, значения возврата имеют существенные различия. Эти различия в основном происходят в функции remove_liquidity.

Атака повторного входа в основном нацелена на функцию remove_liquidity определенного смарт-контракта. Эта функция возвращает токены, добавленные пользователем, при удалении ликвидности. Из-за гомоморфизма Polygon и EVM цепей, при переводе MATIC на контракт срабатывает логика повторного входа.

Дальнейший анализ показал, что проблема заключается в реализации функции getUnderlyingPrice. Эта функция связана с несколькими закрытыми контрактами, что усложняет анализ. Тем не менее, проверяя хранилище и стек вызовов, мы можем сделать вывод о значениях ключевых переменных и путях вызова функций.

Суть атаки заключается в том, что возвращаемое значение функции get_virtual_price существенно изменилось до и после повторного входа. Это изменение связано с моментом обновления переменной self.D. В нормальных условиях self.D должен обновляться после завершения перевода, но в данном случае, из-за повторного входа, произошла ошибка в расчете цены.

Процесс выполнения функции remove_liquidity включает в себя: 1) уничтожение LP-токенов пользователя; 2) отправка средств залога пользователю; 3) обновление значения self.D. Атакующий выполняет повторный вход на втором этапе, используя не своевременно обновленное значение self.D для получения займа, тем самым получая неправомерные выгоды.

Следует отметить, что хотя функция remove_liquidity использует декоратор @nonreentrant('lock') для предотвращения повторного входа, повторный вход злоумышленника в другие контракты для заимствования не дал ожидаемого эффекта для этого замка.

Эта атака выявила важность времени обновления переменных в смарт-контрактах. Для повышения безопасности рекомендуется, чтобы проектные команды приняли следующие меры:

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

Реализуя эти лучшие практики, можно значительно повысить безопасность и стабильность смарт-контрактов, обеспечив более надежную инфраструктуру для экосистемы Web3.