Análisis del incidente de vulnerabilidad de Euler Finance: ataque de flash loan que causó pérdidas de 197 millones de dólares
El 13 de marzo de 2023, el proyecto Euler Finance sufrió un importante incidente de seguridad. Según los datos de monitoreo en cadena, debido a una vulnerabilidad de verificación de liquidez en la función donateToReserves de Etoken, el proyecto fue víctima de un ataque de flash loan. El atacante, a través de múltiples operaciones con diferentes monedas, causó pérdidas de hasta 197 millones de dólares, involucrando 6 tipos de tokens. Actualmente, estos fondos siguen en la cuenta del atacante.
Análisis del proceso de ataque
El atacante primero obtuvo un préstamo flash de 30 millones de Dai de una plataforma de préstamos, y luego desplegó dos contratos: uno para el préstamo y otro para la liquidación.
El atacante depositó 20 millones de Dai en el contrato del Euler Protocol, obteniendo aproximadamente 19.5 millones de eDAI.
Utilizando la función de apalancamiento de 10x de Euler Protocol, el atacante tomó prestados 195.6 millones de eDAI y 200 millones de dDAI.
El atacante usa los 10 millones de DAI restantes para pagar parte de la deuda y destruye la cantidad correspondiente de dDAI, luego vuelve a pedir prestados 195.6 millones de eDAI y 200 millones de dDAI.
Pasos clave: el atacante llama a la función donateToReserves, donando 10 veces la cantidad de fondos a reembolsar, es decir, 100 millones de eDAI. A continuación, el atacante activa la función de liquidación, obteniendo 310 millones de dDAI y 250 millones de eDAI.
Por último, el atacante extrajo 38.9 millones de Dai, devolvió 30 millones de Flash Loans y obtuvo una ganancia final de aproximadamente 8.87 millones de Dai.
Análisis de las causas de la vulnerabilidad
El problema central de este ataque radica en la función donateToReserves. A diferencia de otras funciones clave (como la función mint), la función donateToReserves carece de un paso crucial: checkLiquidity.
La función checkLiquidity tiene como objetivo llamar al módulo RiskManager para verificar al usuario y asegurarse de que el Etoken sea mayor que el Dtoken, garantizando así la situación de liquidez del usuario. Normalmente, esta verificación es necesaria en cada operación. Sin embargo, la función donateToReserves carece de este paso, lo que permite a los atacantes colocarse primero en un estado que puede ser liquidado y luego completar la operación de liquidación.
Consejos de seguridad
Para este tipo de vulnerabilidades, recomendamos que los equipos de proyectos realicen una auditoría de seguridad completa antes de su lanzamiento, para garantizar la seguridad del contrato. Para los proyectos de préstamos, 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 a través de auditorías de seguridad rigurosas y evaluaciones de riesgos exhaustivas se puede minimizar la probabilidad de que ocurran eventos de seguridad similares, garantizando la seguridad de los fondos del proyecto y de los usuarios.
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.
16 me gusta
Recompensa
16
3
Compartir
Comentar
0/400
AirdropChaser
· 08-05 08:04
tomar a la gente por tonta tomar a la gente por tonta Todos los días son tomados por tontos
Ver originalesResponder0
DefiSecurityGuard
· 08-05 08:04
*suspiro* otro día, otro protocolo rekt por la vulnerabilidad básica donateToReserves... lo llamé hace meses, para ser honesto. recordatorio crítico: SIEMPRE sanitiza las verificaciones de liquidez, por el amor de Dios. estos errores de aficionados siguen costando 9 cifras, menuda vergüenza.
Ver originalesResponder0
GasGrillMaster
· 08-05 07:50
Hermano, esta defensa básica no está a la altura, es muy mala.
Euler Finance sufrió un ataque de flash loan de 197 millones de dólares, la vulnerabilidad de la función donateToReserves fue la causa del desastre.
Análisis del incidente de vulnerabilidad de Euler Finance: ataque de flash loan que causó pérdidas de 197 millones de dólares
El 13 de marzo de 2023, el proyecto Euler Finance sufrió un importante incidente de seguridad. Según los datos de monitoreo en cadena, debido a una vulnerabilidad de verificación de liquidez en la función donateToReserves de Etoken, el proyecto fue víctima de un ataque de flash loan. El atacante, a través de múltiples operaciones con diferentes monedas, causó pérdidas de hasta 197 millones de dólares, involucrando 6 tipos de tokens. Actualmente, estos fondos siguen en la cuenta del atacante.
Análisis del proceso de ataque
El atacante primero obtuvo un préstamo flash de 30 millones de Dai de una plataforma de préstamos, y luego desplegó dos contratos: uno para el préstamo y otro para la liquidación.
El atacante depositó 20 millones de Dai en el contrato del Euler Protocol, obteniendo aproximadamente 19.5 millones de eDAI.
Utilizando la función de apalancamiento de 10x de Euler Protocol, el atacante tomó prestados 195.6 millones de eDAI y 200 millones de dDAI.
El atacante usa los 10 millones de DAI restantes para pagar parte de la deuda y destruye la cantidad correspondiente de dDAI, luego vuelve a pedir prestados 195.6 millones de eDAI y 200 millones de dDAI.
Pasos clave: el atacante llama a la función donateToReserves, donando 10 veces la cantidad de fondos a reembolsar, es decir, 100 millones de eDAI. A continuación, el atacante activa la función de liquidación, obteniendo 310 millones de dDAI y 250 millones de eDAI.
Por último, el atacante extrajo 38.9 millones de Dai, devolvió 30 millones de Flash Loans y obtuvo una ganancia final de aproximadamente 8.87 millones de Dai.
Análisis de las causas de la vulnerabilidad
El problema central de este ataque radica en la función donateToReserves. A diferencia de otras funciones clave (como la función mint), la función donateToReserves carece de un paso crucial: checkLiquidity.
La función checkLiquidity tiene como objetivo llamar al módulo RiskManager para verificar al usuario y asegurarse de que el Etoken sea mayor que el Dtoken, garantizando así la situación de liquidez del usuario. Normalmente, esta verificación es necesaria en cada operación. Sin embargo, la función donateToReserves carece de este paso, lo que permite a los atacantes colocarse primero en un estado que puede ser liquidado y luego completar la operación de liquidación.
Consejos de seguridad
Para este tipo de vulnerabilidades, recomendamos que los equipos de proyectos realicen una auditoría de seguridad completa antes de su lanzamiento, para garantizar la seguridad del contrato. Para los proyectos de préstamos, se debe prestar especial atención a los siguientes aspectos:
Solo a través de auditorías de seguridad rigurosas y evaluaciones de riesgos exhaustivas se puede minimizar la probabilidad de que ocurran eventos de seguridad similares, garantizando la seguridad de los fondos del proyecto y de los usuarios.