Euler Finance sufrió un ataque de flash loan que resultó en una pérdida de 197 millones de dólares. La vulnerabilidad del contrato fue la principal causa.
Euler Finance sufrió un ataque de flash loan, con pérdidas cercanas a 200 millones de dólares
El 13 de marzo, el proyecto Euler Finance sufrió un ataque de flash loan debido a una vulnerabilidad en el contrato, lo que resultó en una pérdida de aproximadamente 197 millones de dólares. El atacante aprovechó la falta de verificación de liquidez en la función donateToReserves del proyecto y, a través de múltiples operaciones con diferentes monedas, logró obtener ganancias. Actualmente, los fondos robados siguen retenidos en la cuenta del atacante.
Análisis del proceso de ataque
El atacante primero toma prestados 30 millones de DAI de una plataforma de préstamos a través de un Flash Loans y despliega dos contratos, uno para el préstamo y otro para la liquidación.
Poner 20 millones de DAI en el contrato del Protocolo Euler para obtener 19.5 millones de eDAI.
Utilizar la función de apalancamiento de 10x del Protocolo Euler para pedir prestados 195.6 millones de eDAI y 200 millones de dDAI.
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.
Donando 100 millones de eDAI a través de la función donateToReserves, se llama inmediatamente a la función liquidate para realizar la liquidación, obteniendo 310 millones de dDAI y 250 millones de eDAI.
Finalmente se extrajeron 38.9 millones de DAI, se devolvieron 30 millones de Flash Loans, y la ganancia neta fue de aproximadamente 8.87 millones de DAI.
Análisis de la causa de la vulnerabilidad
La principal razón por la que el ataque tuvo éxito es que la función donateToReserves carece de las verificaciones de liquidez necesarias. A diferencia de otras funciones clave como mint, la función donateToReserves no llama a checkLiquidity para validar la liquidez del usuario. Esto permite que el atacante, a través de operaciones específicas, coloque su cuenta en un estado que puede ser liquidado, y luego complete la liquidación para obtener ganancias.
En condiciones normales, la función checkLiquidity llamará al módulo RiskManager para asegurar que la cantidad de Etokens del usuario siempre sea mayor que la cantidad de Dtokens. Sin embargo, la función donateToReserves omitió este paso crucial, creando una oportunidad para el ataque.
Consejos de seguridad
Este evento resalta una vez más la importancia de la auditoría de seguridad de los contratos inteligentes. Antes de lanzar un proyecto, el equipo del proyecto debe realizar una revisión de seguridad exhaustiva y detallada, especialmente para proyectos de préstamos, donde se debe prestar especial atención a los siguientes aspectos:
Integridad del mecanismo de reembolso de fondos
Integralidad de la detección de liquidez
Seguridad del proceso de liquidación de deudas
Solo asegurando la seguridad de estos aspectos clave se puede prevenir efectivamente la ocurrencia de ataques similares. A medida que el ecosistema Web3 sigue desarrollándose, la seguridad de los contratos inteligentes seguirá siendo un foco de atención en la industria.
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.
12 me gusta
Recompensa
12
6
Republicar
Compartir
Comentar
0/400
LongTermDreamer
· hace21h
Dentro de tres años, volveremos a ver otra historia de regresión de valor. Los que entienden, entienden.
Ver originalesResponder0
GasBandit
· hace21h
¿Otra vez es culpa de los contratos inteligentes? ¿Cómo se audita eso?
Ver originalesResponder0
RektCoaster
· hace21h
Otra bomba, otra vez un desastre.
Ver originalesResponder0
AirdropHarvester
· hace21h
No esperaba que Euler también fracasara... tsk tsk
Ver originalesResponder0
just_here_for_vibes
· hace21h
¿Otra explosión? Homenaje a los que hacen Rug Pull
Ver originalesResponder0
IronHeadMiner
· hace21h
Otra máquina de tomar a la gente por tonta ha fracasado...
Euler Finance sufrió un ataque de flash loan que resultó en una pérdida de 197 millones de dólares. La vulnerabilidad del contrato fue la principal causa.
Euler Finance sufrió un ataque de flash loan, con pérdidas cercanas a 200 millones de dólares
El 13 de marzo, el proyecto Euler Finance sufrió un ataque de flash loan debido a una vulnerabilidad en el contrato, lo que resultó en una pérdida de aproximadamente 197 millones de dólares. El atacante aprovechó la falta de verificación de liquidez en la función donateToReserves del proyecto y, a través de múltiples operaciones con diferentes monedas, logró obtener ganancias. Actualmente, los fondos robados siguen retenidos en la cuenta del atacante.
Análisis del proceso de ataque
El atacante primero toma prestados 30 millones de DAI de una plataforma de préstamos a través de un Flash Loans y despliega dos contratos, uno para el préstamo y otro para la liquidación.
Poner 20 millones de DAI en el contrato del Protocolo Euler para obtener 19.5 millones de eDAI.
Utilizar la función de apalancamiento de 10x del Protocolo Euler para pedir prestados 195.6 millones de eDAI y 200 millones de dDAI.
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.
Donando 100 millones de eDAI a través de la función donateToReserves, se llama inmediatamente a la función liquidate para realizar la liquidación, obteniendo 310 millones de dDAI y 250 millones de eDAI.
Finalmente se extrajeron 38.9 millones de DAI, se devolvieron 30 millones de Flash Loans, y la ganancia neta fue de aproximadamente 8.87 millones de DAI.
Análisis de la causa de la vulnerabilidad
La principal razón por la que el ataque tuvo éxito es que la función donateToReserves carece de las verificaciones de liquidez necesarias. A diferencia de otras funciones clave como mint, la función donateToReserves no llama a checkLiquidity para validar la liquidez del usuario. Esto permite que el atacante, a través de operaciones específicas, coloque su cuenta en un estado que puede ser liquidado, y luego complete la liquidación para obtener ganancias.
En condiciones normales, la función checkLiquidity llamará al módulo RiskManager para asegurar que la cantidad de Etokens del usuario siempre sea mayor que la cantidad de Dtokens. Sin embargo, la función donateToReserves omitió este paso crucial, creando una oportunidad para el ataque.
Consejos de seguridad
Este evento resalta una vez más la importancia de la auditoría de seguridad de los contratos inteligentes. Antes de lanzar un proyecto, el equipo del proyecto debe realizar una revisión de seguridad exhaustiva y detallada, especialmente para proyectos de préstamos, donde se debe prestar especial atención a los siguientes aspectos:
Solo asegurando la seguridad de estos aspectos clave se puede prevenir efectivamente la ocurrencia de ataques similares. A medida que el ecosistema Web3 sigue desarrollándose, la seguridad de los contratos inteligentes seguirá siendo un foco de atención en la industria.