Euler Finance sufrió un ataque de flash loan, con pérdidas de hasta 197 millones de dólares

El 13 de marzo de 2023, el proyecto Euler Finance sufrió un ataque de flash loan debido a una vulnerabilidad en el contrato, lo que resultó en enormes pérdidas. Los atacantes aprovecharon la falta de verificación de liquidez en la función donateToReserves del contrato, obteniendo una gran cantidad de fondos a través de múltiples operaciones. Este incidente involucró 6 tipos de tokens, con una pérdida total de 197 millones de dólares.

Análisis del proceso de ataque

1. El atacante primero tomó prestados 30 millones de DAI de una plataforma de préstamos a través de un Flash Loans y desplegó dos contratos: un contrato de préstamo y un contrato de liquidación.

2. El atacante depositó 20,000,000 DAI en el contrato del Euler Protocol, obteniendo 195,000 eDAI.

3. Utilizando la función de apalancamiento de 10x de Euler Protocol, el atacante tomó prestados 1.956.000 eDAI y 2.000.000 dDAI.

4. El atacante utiliza los 10 millones de DAI restantes para pagar parte de la deuda y quema el dDAI correspondiente, luego vuelve a pedir prestados 1,956,000 eDAI y 2,000,000 dDAI.

5. Pasos clave: el atacante llama a la función donateToReserves y dona 1 millón de eDAI (que es 10 veces el monto a reembolsar). Inmediatamente después, el atacante llama a la función liquidate para llevar a cabo la liquidación, obteniendo 3.1 millones de dDAI y 2.5 millones de eDAI.

6. Por último, el atacante extrajo 389,000 DAI y devolvió 30,000,000 DAI del Flash Loans, obteniendo una ganancia final de 8,870,000 DAI.

Análisis de la causa de la vulnerabilidad

El problema central de este ataque radica en la falta de una verificación de liquidez necesaria en la función donateToReserves del contrato de Euler Finance. A diferencia de la función mint, la función donateToReserves no ejecuta el paso de verificación de liquidez, lo que permite a los atacantes eludir la verificación de liquidez normal.

En condiciones normales, la función checkLiquidity llamará al módulo RiskManager para asegurar que la cantidad de eTokens del usuario sea mayor que la cantidad de dTokens. Sin embargo, debido a que la función donateToReserves carece de este paso clave, el atacante pudo aprovechar esta vulnerabilidad, primero colocándose en un estado que puede ser liquidado y luego completando la operación de liquidación.

Sugerencias de seguridad

Para este tipo de ataque, recomendamos a los proyectos DeFi:

1. Realizar una auditoría de seguridad completa antes del lanzamiento del contrato para garantizar la seguridad del contrato.

2. Para los proyectos de préstamos, es especialmente importante prestar atención a los aspectos clave como el reembolso de fondos, la detección de liquidez y la liquidación de deudas.

3. Se deben implementar controles de liquidez estrictos en cada función que pueda afectar el estado de los fondos del usuario.

4. Realizar revisiones y actualizaciones de código periódicamente, y corregir de inmediato las vulnerabilidades encontradas.

5. Considerar la introducción de mecanismos de firma múltiple o bloqueos temporales como medidas de seguridad adicionales.

Este evento nos recuerda nuevamente que, en el ámbito de DeFi que se desarrolla rápidamente, la seguridad de los contratos siempre es crucial. Los proyectos deben fortalecer constantemente la conciencia de seguridad y adoptar múltiples medidas de protección para salvaguardar la seguridad de los activos de los usuarios.