Primer lanzamiento | CertiK: Yearn.finance nuevo proyecto Eminence análisis de vulnerabilidad de ataque

El 29 de septiembre, hora de Beijing, el equipo de investigación de seguridad de CertiK descubrió transacciones anormales en Eminence.finance, un nuevo proyecto de Yearn.finance. Se transfirieron tres fondos con un valor total de aproximadamente 109 millones de RMB del contrato inteligente de Eminence en la dirección: 0x5ade7ae8660293f2ebfcefaba91d141d72d221e8. El equipo de investigación de seguridad de CertiK cree que el incidente es que el atacante usó un programa de script para pedir prestados fondos iniciales a través de flashloan y usó el modelo Bonding Curve en el proyecto Eminence para comprar y vender repetidamente EMN y eAAVE para obtener ingresos.

El siguiente análisis se basa en:

Tome https://etherscan.io/tx/0x3503253131644dd9f52802d071de74e456570374d586ddd640159cf6fb9b8ad8 como ejemplo, el diagrama de flujo de la transacción es el siguiente:

En esta transacción, el atacante primero tomó prestados 15 millones de DAI a través del servicio Flash Loan en Uniswap y luego compró todos los tokens EMN, comprando un total de aproximadamente 1,383,650,487 tokens EMN.

La mitad de la EMN, un total de aproximadamente 691 825 243 tokens EMN, se utilizó para comprar tokens eAAVE a través del paso OP0, y se obtuvo un total de aproximadamente 572 431 tokens eAAVE.

Hasta la fecha, el atacante posee un total de 1 383 650 487-691 825 243 = 691 825 244 tokens EMN y 572 431 eAAVE.  

A continuación, el script del atacante continuó ejecutando 5 transacciones internas (Transacciones internas), incluidas OP0, OP1, OP2, OP3 y OP4. El impacto de estas 5 transacciones internas es el siguiente:

El monto total de DAI vendido de OP4 fue de 16 673 637, casi 1,7 millones más que el monto total de DAI prestado por el atacante a través de préstamos rápidos de 15 millones. El motivo de los resultados anteriores es: en el proceso de OP0 usando EMN para comprar eAAVE, se llamó a la función de reclamo en la línea 231 del contrato inteligente EminenceCurrency.sol, y luego la función _burn en la línea 233 quemó los 691,825,243 EMN usados ​​para el transacción:

Sin embargo, en la definición de la función _burn en la figura a continuación, podemos ver que solo se quema la cantidad de tokens EMN, mientras que la cantidad correspondiente de DAI no ha cambiado. Esto crea un problema: la proporción de EMN a DAI reduce el precio relativo de DAI debido a la reducción en el número de EMN, por lo tanto, si usa la misma cantidad de EMN para comprar DAI, puede obtener más DAI.

Por lo tanto, cuando se completa OP0, la relación entre el número de EMN y el número de DAI disminuye. El atacante convierte el EMN general restante en DAI a través de OP1. Dado que el precio relativo de DAI es bajo en este momento, la cantidad de DAI comprada es más de lo normal.

Después de completar OP1, el atacante convierte el eAAVE retenido en EMN a través de OP2 y OP3, y luego lo convierte en DAI. Finalmente, antes de OP4, la cantidad de DAI en poder del atacante será mayor que la cantidad prestada de Uniswap.

Hasta el momento, el atacante ha obtenido beneficios a través de la vulnerabilidad.

El atacante explotó la vulnerabilidad tres veces en la misma transacción. Cada vez que se alcanza OP4, el DAI total después de la ganancia se utilizará nuevamente para realizar ataques. Después de completar las tres veces, el atacante pagó el préstamo de Uniswap y envió la ganancia de la transacción a su dirección:

0x223034edbe95823c1160c16f26e3000315171ca9

El atacante ejecutó un total de 3 transacciones y la dirección de la transacción es la siguiente:

Primera vez:

Segunda vez:

0x045b60411af18114f1986957a41296ba2a97ccff75a9b38af818800ea9da0b2a

Tercera vez:

0x4f0f495dbcb58b452f268b9149a418524e43b13b55e780673c10b3b755340317

Este incidente es un caso típico de una brecha de seguridad causada por la inconsistencia entre el diseño lógico y la implementación real del código del contrato inteligente. Y antes de que el proyecto entre en línea, aún no ha pasado la auditoría de seguridad. Para este tipo de vulnerabilidad, los métodos y herramientas de prueba tradicionales no pueden detectar este tipo de vulnerabilidad lógica.

Por ello, CertiK propone lo siguiente:

El auge actual de los proyectos DeFi continúa sin cesar. Con el fin de aprovechar los puntos calientes y las oportunidades, muchos proyectos se han lanzado en línea sin pruebas ni auditorías rigurosas. En estos proyectos, la mayoría de las vulnerabilidades no se pueden encontrar mediante métodos y herramientas de prueba comunes. Esta vulnerabilidad solo se puede descubrir buscando expertos en auditoría profesionales que realicen pruebas rigurosas de modelos matemáticos.

Las auditorías de seguridad ahora son estándar para proyectos DeFi de alta calidad. Si el proyecto no ha sido auditado, para los usuarios, el comportamiento de inversión debe ser extremadamente cauteloso; para la parte del proyecto, es necesario encontrar una empresa auditora profesional y de buena reputación para auditar. Si el proyecto ha sido auditado, es necesario tratar de comprender los antecedentes de la empresa auditora y los indicadores en su informe de auditoría, incluidos, entre otros:

Alcance, método y conclusión de la auditoría de seguridad

¿Existen lagunas o riesgos de seguridad en el contrato? Si es así, es necesario comprender la gravedad de estos problemas y su posible impacto.

Código de calidad del contrato en su conjunto

Profesionalidad e independencia de la firma auditora

Tags：

Dogecoin