Análisis del ataque de reentrada de Flash Loans en el proyecto Jarvis Network
El 15 de enero de 2023, el proyecto Jarvis_Network fue atacado, perdiendo 663,101 MATIC. A través del análisis de la pila de llamadas de las transacciones del ataque, se descubrió que existía una lógica de reentrada. Durante el proceso de reentrada, se realizó una llamada a la misma función del mismo contrato, con los mismos parámetros, pero con valores de retorno muy diferentes.
La reentrada ocurre en la función remove_liquidity. Esta función devuelve los tokens añadidos por el usuario al eliminar la liquidez. Debido a que Polygon es isomórfico con EVM, la transferencia de MATIC al contrato activará la reentrada.
El análisis profundo revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función implica múltiples llamadas a contratos, lo que afecta en última instancia el valor de retorno de la función get_virtual_price. El valor de retorno de la función get_virtual_price está influenciado por la variable self.D, y la actualización de self.D se realiza después de la transferencia.
Cuando el atacante retira liquidez, MATIC se transfiere al contrato de ataque y se llama a la función fallback para consultar el precio. Debido a que self.D se actualiza después de la transferencia, se produce un error en la obtención del precio anterior. El proceso del método de retirada de liquidez es: 1) destruir LP del usuario; 2) enviar fondos de staking al usuario; 3) actualizar self.D.
self.D se utiliza para el cálculo de precios y también se actualizará al agregar liquidez. Los fondos de liquidez del atacante son considerablemente mayores, por lo que, en condiciones normales, el valor de self.D será mucho menor. Sin embargo, el atacante realiza una reentrada en el paso 2 y toma prestado a un precio 10 veces superior al precio original. Esto se debe a que el valor de self.D aumenta al agregar liquidez, pero no se actualiza a tiempo al retirar liquidez.
Aunque el método remove_liquidity utiliza @nonreentrant( 'lock' ) para prevenir reentradas, el atacante reentra en otros contratos para tomar prestados fondos, lo que hace que el candado de reentrada falle.
La principal razón de este ataque es que la lógica de modificación de variables, después de ser llamada externamente, provoca excepciones en la obtención de precios. La reentrada entre contratos hace que el bloqueo de reentrada falle. Se recomienda que el equipo del proyecto realice una auditoría de seguridad rigurosa, coloque la modificación de variables antes de las llamadas externas y utilice un método de obtención de precios de múltiples fuentes de datos. Seguir la norma de codificación "primero juzgar, luego escribir la variable, y después realizar la llamada externa" (Checks-Effects-Interactions) puede aumentar la seguridad y estabilidad del proyecto.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
9 me gusta
Recompensa
9
6
Compartir
Comentar
0/400
All-InQueen
· 08-05 00:42
Cadena de bloques otra vez bajo la tormenta 麻了
Ver originalesResponder0
HalfBuddhaMoney
· 08-02 05:37
No se puede obtener tanto...
Ver originalesResponder0
ZeroRushCaptain
· 08-02 05:37
Otro ha caído, Ahorro total se ha ido a la deriva. ¡Sam Altman, adelante!
Ver originalesResponder0
ForkLibertarian
· 08-02 05:29
La velocidad de mis manos es tan lenta que ya es tarde para reducir pérdidas y hacer un rug pull.
Ver originalesResponder0
StakeTillRetire
· 08-02 05:24
Otro desastre de reentrada, se ha cerrado.
Ver originalesResponder0
SighingCashier
· 08-02 05:13
¿Te has salido de control? Otra vez es una vulnerabilidad de reentrada.
Jarvis Network sufrió un ataque de reingreso de Flash Loans, con una pérdida de 663,101 MATIC.
Análisis del ataque de reentrada de Flash Loans en el proyecto Jarvis Network
El 15 de enero de 2023, el proyecto Jarvis_Network fue atacado, perdiendo 663,101 MATIC. A través del análisis de la pila de llamadas de las transacciones del ataque, se descubrió que existía una lógica de reentrada. Durante el proceso de reentrada, se realizó una llamada a la misma función del mismo contrato, con los mismos parámetros, pero con valores de retorno muy diferentes.
La reentrada ocurre en la función remove_liquidity. Esta función devuelve los tokens añadidos por el usuario al eliminar la liquidez. Debido a que Polygon es isomórfico con EVM, la transferencia de MATIC al contrato activará la reentrada.
El análisis profundo revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función implica múltiples llamadas a contratos, lo que afecta en última instancia el valor de retorno de la función get_virtual_price. El valor de retorno de la función get_virtual_price está influenciado por la variable self.D, y la actualización de self.D se realiza después de la transferencia.
Cuando el atacante retira liquidez, MATIC se transfiere al contrato de ataque y se llama a la función fallback para consultar el precio. Debido a que self.D se actualiza después de la transferencia, se produce un error en la obtención del precio anterior. El proceso del método de retirada de liquidez es: 1) destruir LP del usuario; 2) enviar fondos de staking al usuario; 3) actualizar self.D.
self.D se utiliza para el cálculo de precios y también se actualizará al agregar liquidez. Los fondos de liquidez del atacante son considerablemente mayores, por lo que, en condiciones normales, el valor de self.D será mucho menor. Sin embargo, el atacante realiza una reentrada en el paso 2 y toma prestado a un precio 10 veces superior al precio original. Esto se debe a que el valor de self.D aumenta al agregar liquidez, pero no se actualiza a tiempo al retirar liquidez.
Aunque el método remove_liquidity utiliza @nonreentrant( 'lock' ) para prevenir reentradas, el atacante reentra en otros contratos para tomar prestados fondos, lo que hace que el candado de reentrada falle.
La principal razón de este ataque es que la lógica de modificación de variables, después de ser llamada externamente, provoca excepciones en la obtención de precios. La reentrada entre contratos hace que el bloqueo de reentrada falle. Se recomienda que el equipo del proyecto realice una auditoría de seguridad rigurosa, coloque la modificación de variables antes de las llamadas externas y utilice un método de obtención de precios de múltiples fuentes de datos. Seguir la norma de codificación "primero juzgar, luego escribir la variable, y después realizar la llamada externa" (Checks-Effects-Interactions) puede aumentar la seguridad y estabilidad del proyecto.