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 en la red Polygon, resultando en una pérdida de aproximadamente 663,000 MATIC. El análisis mostró que el atacante utilizó Flash Loans y una vulnerabilidad de reentrada para llevar a cabo el ataque.
El análisis de la pila de llamadas de transacciones de ataque muestra que, durante el proceso de reentrada, al llamar a la misma función del mismo contrato, los parámetros de entrada son los mismos pero los valores de retorno presentan diferencias significativas. Los valores de retorno antes y después de la reentrada son:
Reentrada previa: 1002157321772769944
Reentrada: 10091002696492234934
La reentrada ocurre en la función remove_liquidity. Esta función devuelve los tokens que el usuario añadió al eliminar liquidez. Debido a que Polygon es compatible con EVM, se activó la reentrada al transferir MATIC al contrato.
Un análisis profundo revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función implica una serie de cálculos internos y llamadas externas, siendo clave el valor de retorno de la función get_virtual_price. El valor de retorno de esta función se ve afectado por la variable self.D, y la actualización de self.D ocurre después de la transferencia de tokens.
El atacante, al retirar liquidez, transfirió MATIC al contrato atacante y consultó primero el precio del token a través de un callback. Dado que self.D aún no se había actualizado, esto provocó un error en la obtención del precio. El atacante aprovechó esta discrepancia temporal y, al reingresar, elevó el precio del préstamo en aproximadamente 10 veces.
Aunque la función remove_liquidity utiliza el decorador @nonreentrant('lock') para prevenir la reentrada, los atacantes eludieron este mecanismo de protección a través de la reentrada entre contratos.
Este ataque expuso varios problemas clave:
La lógica de modificación de variables se encuentra después de la llamada externa, lo que provoca una excepción en la obtención del precio.
La reentrada entre contratos hace que el bloqueo de reentrada sea ineficaz.
No se siguió el patrón "Comprobaciones-Efectos-Interacciones" (Checks-Effects-Interactions).
Para prevenir ataques similares, se sugiere a los proyectos:
Realizar auditorías de seguridad estrictas
Coloca la modificación de variables antes de la llamada externa
Obtención de precios mediante múltiples fuentes de datos
Seguir la norma de codificación "Verificar - Efectuar - Interactuar"
A través de estas medidas, se puede mejorar significativamente la seguridad y la 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.
Jarvis Network sufrió un ataque de reingreso por Flash Loans, con una pérdida de 66.3 mil 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 en la red Polygon, resultando en una pérdida de aproximadamente 663,000 MATIC. El análisis mostró que el atacante utilizó Flash Loans y una vulnerabilidad de reentrada para llevar a cabo el ataque.
El análisis de la pila de llamadas de transacciones de ataque muestra que, durante el proceso de reentrada, al llamar a la misma función del mismo contrato, los parámetros de entrada son los mismos pero los valores de retorno presentan diferencias significativas. Los valores de retorno antes y después de la reentrada son:
La reentrada ocurre en la función remove_liquidity. Esta función devuelve los tokens que el usuario añadió al eliminar liquidez. Debido a que Polygon es compatible con EVM, se activó la reentrada al transferir MATIC al contrato.
Un análisis profundo revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función implica una serie de cálculos internos y llamadas externas, siendo clave el valor de retorno de la función get_virtual_price. El valor de retorno de esta función se ve afectado por la variable self.D, y la actualización de self.D ocurre después de la transferencia de tokens.
El atacante, al retirar liquidez, transfirió MATIC al contrato atacante y consultó primero el precio del token a través de un callback. Dado que self.D aún no se había actualizado, esto provocó un error en la obtención del precio. El atacante aprovechó esta discrepancia temporal y, al reingresar, elevó el precio del préstamo en aproximadamente 10 veces.
Aunque la función remove_liquidity utiliza el decorador @nonreentrant('lock') para prevenir la reentrada, los atacantes eludieron este mecanismo de protección a través de la reentrada entre contratos.
Este ataque expuso varios problemas clave:
Para prevenir ataques similares, se sugiere a los proyectos:
A través de estas medidas, se puede mejorar significativamente la seguridad y la estabilidad del proyecto.