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, lo que resultó en el robo de 663,101 MATIC. Este incidente ha generado preocupación por la seguridad del proyecto.
A través del análisis de la pila de llamadas de transacciones, se descubrió que el atacante aprovechó una vulnerabilidad de reentrada. Durante el proceso de reentrada, aunque los parámetros de entrada sean los mismos, los valores de retorno de la misma función del mismo contrato muestran diferencias significativas. Esta diferencia ocurre principalmente en la función remove_liquidity.
Los ataques de reentrada se dirigen principalmente a la función remove_liquidity de un contrato inteligente. Esta función devuelve los tokens añadidos por el usuario al eliminar liquidez. Debido a la homogeneidad de Polygon y las cadenas EVM, se activa la lógica de reentrada cuando se transfieren MATIC al contrato.
Un análisis más detallado revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función involucra varios contratos que no están abiertos, lo que aumenta la dificultad del análisis. Sin embargo, al revisar los espacios de almacenamiento y la pila de llamadas, podemos inferir los valores de las variables clave y la ruta de llamada de la función.
El núcleo del ataque radica en el valor de retorno de la función get_virtual_price que experimenta un cambio significativo antes y después de la reentrada. Este cambio está relacionado con el momento de actualización de la variable self.D. Normalmente, self.D debería actualizarse después de que se complete la transferencia, pero en este ataque, debido a la reentrada, se produce un error en el cálculo del precio.
El flujo de ejecución de la función remove_liquidity incluye: 1) destruir los tokens LP del usuario; 2) enviar los fondos apostados al usuario; 3) actualizar el valor de self.D. El atacante realiza una reentrada en el segundo paso, aprovechando el valor de self.D que no se actualizó a tiempo para pedir un préstamo, obteniendo así beneficios indebidos.
Es importante señalar que, aunque la función remove_liquidity utiliza el decorador @nonreentrant('lock') para prevenir la reentrada, este bloqueo de reentrada no tuvo el efecto esperado, ya que el atacante, tras la reentrada, accedió a otros contratos para realizar préstamos.
Este ataque expuso la importancia del momento de la actualización de variables en los contratos inteligentes. Para mejorar la seguridad, se recomienda que las partes del proyecto tomen las siguientes medidas:
Realizar auditorías de seguridad rigurosas
Asegúrese de que las modificaciones de las variables se completen antes de la llamada externa.
Obtener información de precios utilizando múltiples fuentes de datos
Escriba el código siguiendo el patrón "Checks-Effects-Interactions".
Al implementar estas mejores prácticas, se puede mejorar significativamente la seguridad y estabilidad de los contratos inteligentes, proporcionando una infraestructura más confiable para el ecosistema Web3.
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.
8 me gusta
Recompensa
8
4
Compartir
Comentar
0/400
CantAffordPancake
· 08-06 06:46
Otra vez han tomado a la gente por tonta~
Ver originalesResponder0
RugpullTherapist
· 08-06 06:44
¿Otro proyecto que hace un Rug Pull?? ¡Triste~
Ver originalesResponder0
not_your_keys
· 08-06 06:31
¡Otro proyecto ha sido aprovechado!
Ver originalesResponder0
GateUser-a180694b
· 08-06 06:24
¿No es demasiado superficial esta auditoría de código?!
Jarvis Network sufrió un ataque de reentrada por Flash Loans, se robaron 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, lo que resultó en el robo de 663,101 MATIC. Este incidente ha generado preocupación por la seguridad del proyecto.
A través del análisis de la pila de llamadas de transacciones, se descubrió que el atacante aprovechó una vulnerabilidad de reentrada. Durante el proceso de reentrada, aunque los parámetros de entrada sean los mismos, los valores de retorno de la misma función del mismo contrato muestran diferencias significativas. Esta diferencia ocurre principalmente en la función remove_liquidity.
Los ataques de reentrada se dirigen principalmente a la función remove_liquidity de un contrato inteligente. Esta función devuelve los tokens añadidos por el usuario al eliminar liquidez. Debido a la homogeneidad de Polygon y las cadenas EVM, se activa la lógica de reentrada cuando se transfieren MATIC al contrato.
Un análisis más detallado revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función involucra varios contratos que no están abiertos, lo que aumenta la dificultad del análisis. Sin embargo, al revisar los espacios de almacenamiento y la pila de llamadas, podemos inferir los valores de las variables clave y la ruta de llamada de la función.
El núcleo del ataque radica en el valor de retorno de la función get_virtual_price que experimenta un cambio significativo antes y después de la reentrada. Este cambio está relacionado con el momento de actualización de la variable self.D. Normalmente, self.D debería actualizarse después de que se complete la transferencia, pero en este ataque, debido a la reentrada, se produce un error en el cálculo del precio.
El flujo de ejecución de la función remove_liquidity incluye: 1) destruir los tokens LP del usuario; 2) enviar los fondos apostados al usuario; 3) actualizar el valor de self.D. El atacante realiza una reentrada en el segundo paso, aprovechando el valor de self.D que no se actualizó a tiempo para pedir un préstamo, obteniendo así beneficios indebidos.
Es importante señalar que, aunque la función remove_liquidity utiliza el decorador @nonreentrant('lock') para prevenir la reentrada, este bloqueo de reentrada no tuvo el efecto esperado, ya que el atacante, tras la reentrada, accedió a otros contratos para realizar préstamos.
Este ataque expuso la importancia del momento de la actualización de variables en los contratos inteligentes. Para mejorar la seguridad, se recomienda que las partes del proyecto tomen las siguientes medidas:
Al implementar estas mejores prácticas, se puede mejorar significativamente la seguridad y estabilidad de los contratos inteligentes, proporcionando una infraestructura más confiable para el ecosistema Web3.