Euler Finance sufrió un ataque de flash loan, con pérdidas cercanas a 200 millones de dólares

Recientemente, el proyecto Euler Finance sufrió un ataque de flash loan debido a una vulnerabilidad en su contrato inteligente, lo que resultó en una gran pérdida de fondos. Este artículo realizará un análisis detallado de este evento.

Resumen del evento

El 13 de marzo de 2023, la función donateToReserves en el contrato Etoken del proyecto Euler Finance carecía de la verificación de liquidez necesaria, lo que fue aprovechado por los atacantes para llevar a cabo un ataque de flash loan. Los atacantes, mediante múltiples operaciones con diferentes criptomonedas, causaron una pérdida de aproximadamente 197 millones de dólares, que involucró a 6 tipos de tokens. Actualmente, los fondos robados siguen retenidos en la cuenta del atacante.

Análisis del proceso de ataque

1. El atacante primero pidió prestado 30 millones de DAI mediante un ataque de flash loan de alguna plataforma de préstamos y desplegó un contrato de préstamo y un contrato de liquidación.

2. A través de la función deposit, se depositan 20 millones de DAI en el contrato del Euler Protocol, obteniendo 19.5 millones de eDAI.

3. Utilizando la función de apalancamiento de 10x de Euler Protocol, se prestaron 195.6 millones de eDAI y 200 millones de dDAI.

4. Utilizar los 10 millones de DAI restantes para pagar parte de la deuda y destruir la cantidad correspondiente de dDAI, y luego volver a pedir prestada la misma cantidad de eDAI y dDAI.

5. Llamar a la función donateToReserves para donar 100 millones de eDAI, y luego liquidar a través de la función liquidate para obtener 310 millones de dDAI y 250 millones de eDAI.

6. Finalmente, se retiraron 38.9 millones de DAI a través de la función withdraw, se devolvieron 300,000 DAI en un ataque de flash loan, obteniendo una ganancia neta de 8.87 millones de DAI.

Análisis de la causa del fallo

Después de la revisión del código, se encontró que el problema radica en la función donateToReserves. En comparación con funciones clave como mint, la función donateToReserves carece del importante paso checkLiquidity.

La función checkLiquidity generalmente invoca el módulo RiskManager para verificar al usuario, asegurando que la cantidad de Etokens sea mayor que la de Dtokens. Dado que la función donateToReserves no realiza esta verificación, un atacante puede aprovechar ciertas funciones del protocolo para colocarse primero en un estado que puede ser liquidado, y luego completar la liquidación para obtener ganancias.

Sugerencias de seguridad

Para este tipo de ataques, el equipo del proyecto debe tener en cuenta los siguientes puntos:

1. Antes de lanzar el contrato, se debe realizar una auditoría de seguridad completa para garantizar la seguridad del contrato.

2. Los proyectos de préstamos deben centrarse en aspectos clave como el reembolso de fondos, la detección de liquidez y la liquidación de deudas.

3. Todas las funciones que puedan afectar el estado de los activos del usuario deben incluir mecanismos de verificación de seguridad necesarios.

4. Realizar revisiones de código periódicas y un programa de recompensas por vulnerabilidades para detectar y corregir amenazas potenciales a tiempo.

5. Establecer un mecanismo de respuesta de emergencia, para que se puedan tomar medidas de remedio de manera rápida en caso de un evento de ataque.

Con el continuo desarrollo de los proyectos DeFi, los problemas de seguridad son cada vez más importantes. Los equipos de los proyectos deben mantenerse alerta en todo momento, tomar medidas de protección de seguridad integrales y proporcionar una fuerte garantía para la seguridad de los activos de los usuarios.