Анализ атаки повторного входа на проект Jarvis Network с использованием срочных займов
15 января 2023 года проект Jarvis_Network подвергся атаке, в результате которой было потеряно 663,101 MATIC. Анализ стека вызовов атакующей транзакции показал наличие логики повторного входа. В процессе повторного входа при вызове одной и той же функции одного и того же контракта передавались одинаковые параметры, но возвращаемые значения значительно различались.
Реинъекция происходит в функции remove_liquidity. Эта функция возвращает токены, добавленные пользователем, при удалении ликвидности. Поскольку Polygon совместим с EVM, передача MATIC на контракт вызывает реинъекцию.
Глубокий анализ показал, что проблема заключается в реализации функции getUnderlyingPrice. Эта функция включает несколько вызовов контрактов, которые в конечном итоге влияют на возвращаемое значение функции get_virtual_price. Возвращаемое значение функции get_virtual_price зависит от переменной self.D, а обновление self.D происходит после перевода.
Атакующий, удаляя ликвидность, переводит MATIC на атакующий контракт, после чего вызывается функция fallback для проверки цены. Поскольку обновление self.D происходит после перевода, это приводит к неправильному получению предыдущей цены. Процесс удаления ликвидности следующий: 1) уничтожает LP пользователя; 2) отправляет средства, заложенные пользователем; 3) обновляет self.D.
self.D используется для расчета цены и также обновляется при добавлении ликвидности. Ликвидность злоумышленника значительно больше, поэтому в нормальных условиях значение self.D будет гораздо меньше. Однако злоумышленник выполняет повторный вход на шаге 2 и занимает средства по цене, в 10 раз превышающей первоначальную цену. Это происходит потому, что значение self.D увеличивается при добавлении ликвидности, но не обновляется своевременно при ее удалении.
Хотя метод remove_liquidity использует @nonreentrant('lock') для предотвращения повторного входа, злоумышленник может повторно войти в другие контракты для заимствования средств, что делает блокировку повторного входа неэффективной.
Основная причина этой атаки заключается в том, что логика изменения переменных после внешнего вызова приводит к аномальному получению цены. Межконтрактный повторный вход делает блокировку повторного входа неэффективной. Рекомендуется проектной команде провести строгий аудит безопасности, поместить изменение переменных перед внешними вызовами и использовать способ получения цены с нескольких источников данных. Соблюдение кодового стандарта "сначала проверка, затем запись в переменную, затем внешний вызов" (Checks-Effects-Interactions) может повысить безопасность и стабильность проекта.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
9 Лайков
Награда
9
5
Поделиться
комментарий
0/400
HalfBuddhaMoney
· 08-02 05:37
И не так много можно зарабатывать...
Посмотреть ОригиналОтветить0
ZeroRushCaptain
· 08-02 05:37
Опять один погиб, все сбережения на ветер. Убытки, Сэм Альтман, вперед!
Посмотреть ОригиналОтветить0
ForkLibertarian
· 08-02 05:29
Такая медленная скорость рук, сокращение потерь и мошенничество уже запоздало.
Посмотреть ОригиналОтветить0
StakeTillRetire
· 08-02 05:24
Ещё одна трагедия повторного входа, закрыто.
Посмотреть ОригиналОтветить0
SighingCashier
· 08-02 05:13
Снова провалились, это снова уязвимость повторного входа.
Сеть Jarvis подверглась атаке повторного входа Срочных займов, убыток составил 663,101 MATIC
Анализ атаки повторного входа на проект Jarvis Network с использованием срочных займов
15 января 2023 года проект Jarvis_Network подвергся атаке, в результате которой было потеряно 663,101 MATIC. Анализ стека вызовов атакующей транзакции показал наличие логики повторного входа. В процессе повторного входа при вызове одной и той же функции одного и того же контракта передавались одинаковые параметры, но возвращаемые значения значительно различались.
Реинъекция происходит в функции remove_liquidity. Эта функция возвращает токены, добавленные пользователем, при удалении ликвидности. Поскольку Polygon совместим с EVM, передача MATIC на контракт вызывает реинъекцию.
! Анализ инцидентов атаки на повторный вход в сеть Jarvis Network
Глубокий анализ показал, что проблема заключается в реализации функции getUnderlyingPrice. Эта функция включает несколько вызовов контрактов, которые в конечном итоге влияют на возвращаемое значение функции get_virtual_price. Возвращаемое значение функции get_virtual_price зависит от переменной self.D, а обновление self.D происходит после перевода.
Атакующий, удаляя ликвидность, переводит MATIC на атакующий контракт, после чего вызывается функция fallback для проверки цены. Поскольку обновление self.D происходит после перевода, это приводит к неправильному получению предыдущей цены. Процесс удаления ликвидности следующий: 1) уничтожает LP пользователя; 2) отправляет средства, заложенные пользователем; 3) обновляет self.D.
self.D используется для расчета цены и также обновляется при добавлении ликвидности. Ликвидность злоумышленника значительно больше, поэтому в нормальных условиях значение self.D будет гораздо меньше. Однако злоумышленник выполняет повторный вход на шаге 2 и занимает средства по цене, в 10 раз превышающей первоначальную цену. Это происходит потому, что значение self.D увеличивается при добавлении ликвидности, но не обновляется своевременно при ее удалении.
Хотя метод remove_liquidity использует @nonreentrant('lock') для предотвращения повторного входа, злоумышленник может повторно войти в другие контракты для заимствования средств, что делает блокировку повторного входа неэффективной.
Основная причина этой атаки заключается в том, что логика изменения переменных после внешнего вызова приводит к аномальному получению цены. Межконтрактный повторный вход делает блокировку повторного входа неэффективной. Рекомендуется проектной команде провести строгий аудит безопасности, поместить изменение переменных перед внешними вызовами и использовать способ получения цены с нескольких источников данных. Соблюдение кодового стандарта "сначала проверка, затем запись в переменную, затем внешний вызов" (Checks-Effects-Interactions) может повысить безопасность и стабильность проекта.