Análisis del ataque de reentrada de Flash Loans en Jarvis Network

Recientemente, un proyecto llamado Jarvis_Network sufrió un ataque de reentrada de Flash Loans, lo que resultó en la pérdida de aproximadamente 663,000 tokens MATIC. Este incidente ocurrió en la noche del 15 de enero de 2023.

A través de un análisis profundo de la pila de llamadas de transacciones, descubrimos que el atacante aprovechó una vulnerabilidad de reingreso. Durante el proceso de reingreso, se realizaron múltiples llamadas a la misma función del mismo contrato, pero el valor de retorno de cada llamada presentaba una gran diferencia. Esta diferencia se manifiesta principalmente en la función remove_liquidity.

Los ataques de reentrada ocurren durante el proceso de eliminación de liquidez. Dado que Polygon y EVM son cadenas homomorfas, cuando se transfiere MATIC al contrato, se activa la lógica de reentrada del contrato. A través de un análisis detallado de la pila de llamadas, encontramos que el problema radica en la función getUnderlyingPrice.

Una investigación más profunda reveló que los atacantes aprovecharon una vulnerabilidad en el momento de actualización de la variable self.D al eliminar la liquidez. Normalmente, el flujo del método remove_liquidity debería ser: 1) destruir el LP del usuario; 2) enviar los fondos apostados al usuario; 3) actualizar self.D. Sin embargo, los atacantes realizaron una operación de reentrada en el segundo paso, lo que provocó un error grave en el cálculo de precios.

A pesar de que la función remove_liquidity utiliza el decorador @nonreentrant('lock') para prevenir la reentrada, este bloqueo de reentrada no funcionó debido a que el atacante reentró en otros contratos para tomar prestados fondos.

Este ataque expuso principalmente dos problemas:

1. La lógica de modificación de variables se encuentra después de la llamada externa, lo que provoca una anomalía en la obtención del precio.
2. La reinserción entre contratos hace que el bloqueo de reinserción sea ineficaz.

Para prevenir ataques similares, se recomienda que los desarrolladores del proyecto tomen las siguientes medidas:

1. Asegúrate de que el código haya pasado por una auditoría de seguridad rigurosa.
2. Coloca la modificación de variables antes de la llamada externa.
3. Utilizar múltiples fuentes de datos para obtener precios.
4. Seguir la norma de codificación "primero juzgar, luego escribir en la variable, y después realizar la llamada externa" (Checks-Effects-Interactions).

Al adoptar estas medidas, el proyecto puede mejorar significativamente su seguridad y estabilidad, proporcionando a los usuarios un servicio más confiable.