Análisis del ataque por reentrada de Flash Loans en el proyecto Jarvis Network
Los datos muestran que el 15 de enero de 2023 a las 17:43:37 UTC, el proyecto Jarvis_Network fue atacado, con una pérdida de 663,101 MATIC.
Al analizar la pila de llamadas de la transacción, se encuentra que hay una lógica de reentrada durante el proceso de eliminación de liquidez. La llamada a la misma función del mismo contrato antes y después de la reentrada utiliza los mismos parámetros, pero los valores de retorno son enormemente diferentes:
Reentrada previa: 1,002,157,321,772,769,944
Reentrada: 10,091,002,696,492,234,934
La reentrada ocurre en la función remove_liquidity. Esta función devuelve los tokens añadidos por el usuario al eliminar la liquidez. Dado que Polygon y EVM son cadenas isomórficas, al transferir MATIC al contrato se activará la reentrada del contrato.
Un análisis profundo revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función involucra 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 la función get_virtual_price se ve afectado por la variable self.D. En la función remove_liquidity, la actualización de self.D ocurre después de la transferencia de tokens. Cuando el atacante retira liquidez, MATIC se transfiere al contrato del atacante, y al llamar a fallback se consulta primero el precio del token. Dado que self.D aún no se ha actualizado, esto provoca un error en la obtención del precio.
Proceso de la función remove_liquidity:
Destruir LP de usuario
Enviar fondos de participación del usuario
Actualizar self.D
El atacante realizó un reingreso en el paso 2, utilizando un valor de self.D no actualizado para tomar préstamos, obteniendo fondos 10 veces superiores al precio normal.
Aunque la función remove_liquidity utiliza @nonreentrant('lock') para prevenir reentradas, los atacantes han eludido este mecanismo de protección a través de reentradas entre contratos.
Este ataque expuso varios problemas clave:
La lógica de modificación de variables después de la llamada externa provoca una anomalía en la obtención de precios.
La reentrada entre contratos hace que el bloqueo de reentrada sea ineficaz
No seguir el patrón "Comprobaciones-Efectos-Interacciones" (Checks-Effects-Interactions)
Para mejorar la seguridad, el equipo del proyecto debe:
Realizar auditorías de seguridad rigurosas
Colocar la modificación de la variable antes de la llamada externa
Adopte múltiples fuentes de datos para obtener precios
Seguir la norma de codificación "evaluar primero, luego escribir en la variable y después realizar la llamada externa"
A través de estas medidas, se puede mejorar significativamente la seguridad y estabilidad del proyecto, previniendo efectivamente ataques similares.
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.
11 me gusta
Recompensa
11
5
Compartir
Comentar
0/400
DisillusiionOracle
· 07-25 05:19
Otra vez peces han sido asesinados por explosivos.
Ver originalesResponder0
FlatlineTrader
· 07-23 14:13
Otra vez un tonto recibe su caja de comida.
Ver originalesResponder0
MidnightGenesis
· 07-23 14:09
El nivel de ofuscación del código no es suficiente, esto debería haber sucedido antes.
Ver originalesResponder0
CryptoGoldmine
· 07-23 13:59
Otra evidencia de datos: los contratos inteligentes registraron una pérdida de ingresos de 65w
Jarvis Network sufrió un ataque de reentrada mediante Flash Loans, con una pérdida de 663,101 MATIC.
Análisis del ataque por reentrada de Flash Loans en el proyecto Jarvis Network
Los datos muestran que el 15 de enero de 2023 a las 17:43:37 UTC, el proyecto Jarvis_Network fue atacado, con una pérdida de 663,101 MATIC.
Al analizar la pila de llamadas de la transacción, se encuentra que hay una lógica de reentrada durante el proceso de eliminación de liquidez. La llamada a la misma función del mismo contrato antes y después de la reentrada utiliza los mismos parámetros, pero los valores de retorno son enormemente 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. Dado que Polygon y EVM son cadenas isomórficas, al transferir MATIC al contrato se activará la reentrada del contrato.
Un análisis profundo revela que el problema radica en la implementación de la función getUnderlyingPrice. Esta función involucra 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 la función get_virtual_price se ve afectado por la variable self.D. En la función remove_liquidity, la actualización de self.D ocurre después de la transferencia de tokens. Cuando el atacante retira liquidez, MATIC se transfiere al contrato del atacante, y al llamar a fallback se consulta primero el precio del token. Dado que self.D aún no se ha actualizado, esto provoca un error en la obtención del precio.
Proceso de la función remove_liquidity:
El atacante realizó un reingreso en el paso 2, utilizando un valor de self.D no actualizado para tomar préstamos, obteniendo fondos 10 veces superiores al precio normal.
Aunque la función remove_liquidity utiliza @nonreentrant('lock') para prevenir reentradas, los atacantes han eludido este mecanismo de protección a través de reentradas entre contratos.
Este ataque expuso varios problemas clave:
Para mejorar la seguridad, el equipo del proyecto debe:
A través de estas medidas, se puede mejorar significativamente la seguridad y estabilidad del proyecto, previniendo efectivamente ataques similares.