Análisis del ataque de reentrada de Flash Loans en Jarvis Network
El 15 de enero de 2023, el proyecto Jarvis_Network fue atacado por hackers, perdiendo 663101 MATIC. A través del análisis de los datos de transacciones, se descubrió que el ataque involucró Flash Loans y una vulnerabilidad de reentrada.
Los atacantes explotaron una vulnerabilidad en la función remove_liquidity. Al eliminar la liquidez, esta función devuelve los tokens añadidos por el usuario. Dado que Polygon y EVM son cadenas isomórficas, la transferencia de MATIC al contrato activará la lógica de reentrada del contrato.
Presta atención al proceso de llamada a la función getUnderlyingPrice. Esta función involucra la interacción de varios contratos, algunos de los cuales no están abiertos. Al analizar, se descubrió que el problema reside en el valor de retorno de la función get_virtual_price. Este valor de retorno muestra diferencias significativas antes y después de la reentrada.
En concreto, la actualización de la variable self.D ocurre después de la transferencia del token. Cuando el atacante retira liquidez, MATIC se transfiere al contrato del atacante. Al llamar a la función de retorno de llamada fallback, el atacante consulta primero el precio de un token determinado. Dado que la actualización de self.D se retrasa respecto a la transferencia, esto provoca un error en la obtención del precio anterior.
El proceso de eliminar liquidez incluye: 1) destruir los tokens LP del usuario; 2) enviar fondos apostados al usuario; 3) actualizar el valor de self.D. self.D se utiliza para el cálculo de precios y se actualiza al agregar y eliminar liquidez. El atacante aprovechó la vulnerabilidad de la gran liquidez y el momento de actualización de self.D, realizando un reingreso en el paso 2 y prestando a un precio 10 veces superior al precio original.
Aunque la función remove_liquidity utiliza el decorador @nonreentrant('lock') para prevenir reentradas, los atacantes eludieron este mecanismo de protección a través de préstamos entre contratos.
Este ataque expone las deficiencias del proyecto en la lógica de modificación de variables y la seguridad de las llamadas entre contratos. Para prevenir ataques similares, se recomienda que el equipo del proyecto implemente las siguientes medidas:
Realizar auditorías de seguridad estrictas.
Coloca la modificación de variables antes de la llamada externa.
Utilizar múltiples fuentes de datos para obtener precios.
Seguir la norma de codificación "Checks-Effects-Interactions".
A través de estas medidas, se puede mejorar significativamente la seguridad y estabilidad del proyecto, evitando que ocurran eventos de ataque similares nuevamente.
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.
22 me gusta
Recompensa
22
6
Compartir
Comentar
0/400
NFTHoarder
· hace8h
La prueba de este proyecto es demasiado débil, se rompe con un solo golpe.
Ver originalesResponder0
RektDetective
· 07-19 06:12
Otra persona tuvo un accidente, no se realizan chequeos de transferencia de matic, ¿novato escribiendo código?
Ver originalesResponder0
DuskSurfer
· 07-18 23:29
Todavía estás acostado copiando contratos, ni siquiera entiendes la reentrada~
Ver originalesResponder0
StableGenius
· 07-18 23:29
lmao otro día otro hack... como se predijo, la verdad
Ver originalesResponder0
HypotheticalLiquidator
· 07-18 23:18
¿Volvió a cometer el mismo viejo error? ¿No va a bloquear una cerradura de reentrada?
Ver originalesResponder0
failed_dev_successful_ape
· 07-18 23:11
El equipo detrás del proyecto está durmiendo mientras otros están forzando la cerradura.
Jarvis Network sufrió un ataque de reentrada por Flash Loans, perdiendo 66 mil MATIC
Análisis del ataque de reentrada de Flash Loans en Jarvis Network
El 15 de enero de 2023, el proyecto Jarvis_Network fue atacado por hackers, perdiendo 663101 MATIC. A través del análisis de los datos de transacciones, se descubrió que el ataque involucró Flash Loans y una vulnerabilidad de reentrada.
Los atacantes explotaron una vulnerabilidad en la función remove_liquidity. Al eliminar la liquidez, esta función devuelve los tokens añadidos por el usuario. Dado que Polygon y EVM son cadenas isomórficas, la transferencia de MATIC al contrato activará la lógica de reentrada del contrato.
Presta atención al proceso de llamada a la función getUnderlyingPrice. Esta función involucra la interacción de varios contratos, algunos de los cuales no están abiertos. Al analizar, se descubrió que el problema reside en el valor de retorno de la función get_virtual_price. Este valor de retorno muestra diferencias significativas antes y después de la reentrada.
En concreto, la actualización de la variable self.D ocurre después de la transferencia del token. Cuando el atacante retira liquidez, MATIC se transfiere al contrato del atacante. Al llamar a la función de retorno de llamada fallback, el atacante consulta primero el precio de un token determinado. Dado que la actualización de self.D se retrasa respecto a la transferencia, esto provoca un error en la obtención del precio anterior.
El proceso de eliminar liquidez incluye: 1) destruir los tokens LP del usuario; 2) enviar fondos apostados al usuario; 3) actualizar el valor de self.D. self.D se utiliza para el cálculo de precios y se actualiza al agregar y eliminar liquidez. El atacante aprovechó la vulnerabilidad de la gran liquidez y el momento de actualización de self.D, realizando un reingreso en el paso 2 y prestando a un precio 10 veces superior al precio original.
Aunque la función remove_liquidity utiliza el decorador @nonreentrant('lock') para prevenir reentradas, los atacantes eludieron este mecanismo de protección a través de préstamos entre contratos.
Este ataque expone las deficiencias del proyecto en la lógica de modificación de variables y la seguridad de las llamadas entre contratos. Para prevenir ataques similares, se recomienda que el equipo del proyecto implemente las siguientes medidas:
A través de estas medidas, se puede mejorar significativamente la seguridad y estabilidad del proyecto, evitando que ocurran eventos de ataque similares nuevamente.