Decodificación de ataques en Alpha y Cream: cuando se pone a prueba la cooperación DeFi. El artículo relata el hackeo reciente y las lecciones para el espacio DeFi.
En 10 minutos, el precio de la CREMA a veces colapsó más del 30%, ¡el precio de ALFA también cayó bruscamente!
El reciente ataque Cream se considera uno de los ataques más complejos en la historia de DeFi. Esta es una buena historia sobre cómo poner a prueba la cooperación en DeFi, una lección que cualquier proyecto o inversor debería tener en cuenta.
Se hace referencia al siguiente artículo de muchas fuentes para enviarle el progreso del ataque, analizar ese evento y las lecciones aprendidas para desarrollar el espacio DeFi para que sea cada vez mejor.
¡Empecemos!
Desarrollos
A continuación se muestra el contrato del hack: https://etherscan.io/tx/0x745ddedf268f60ea4a038991d46b33b7a1d4e5a9ff2767cdba2d3af69f43eb1b
El IronBank de Cream fue pirateado, por un total de $ 37,5 millones en daños.
Según la información de la transacción, el atacante usa Alpha Homora y toma prestados USD de IronBank, cada vez el doble.
Nota : Iron Bank es un nuevo producto de Cream, a través de los proyectos incluidos en la lista blanca de Iron Bank podrán tomar prestados activos de Cream SIN garantía.
Los detalles se pueden encontrar aquí.
El atacante primero realiza 2 transacciones y envía activos a IronBank para recibir cySUSD. Luego, usando flashloan de Aave v2, procedió a convertir USDC a sUSD a través de Curve.

Luego, el atacante envía sUSD a IronBank, lo que le permite continuar tomando prestado, prestando y recibiendo cySUSD (parte de los sUSD se usa para pagar las tarifas de transacción). Además, se tomaron prestados 10 millones de USD mediante préstamos flash y se siguieron utilizando para aumentar la cantidad de cySUSD.
Al final, el atacante poseía tanto cySUSD que pudo pedir prestado cualquier cosa a Ironbank.
![Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi]()
En este punto, el atacante toma prestado:
- 13.2K PESO
- 3,6 millones USDC
- 5,6 millones de billones de dólares
- 4,2 M DE LARGO
![Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi]()
Finalmente el:
- Deposite monedas estables en Aave V2.
- 1k ETH “caridad: Volver a IronBank y Homora.
- Lavado de dinero (220 ETH) a través de Tornado Cash.
- Y los aproximadamente 11k ETH restantes están en la dirección de la billetera del atacante.
![Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi]()
Comienza el drama!!
El ataque causó mucho daño a Cream Finance, pero pronto el proyecto tuiteó que su protocolo funcionaba correctamente y no había sido pirateado.
Si Cream no era la víctima, ¿quién era el atacado? Todos los ojos comenzaron a centrarse en Alpha Finance, pero el proyecto tenía pasos de procesamiento rápidos e información completamente actualizada para los usuarios después de solo unas pocas horas.
Una descripción general de los informes de incidentes de Alpha
- El atacante toma prestado ETH de Cream's Ironbank usando sUSD como garantía.
- El atacante devuelve el préstamo sUSD. Sin embargo, debido a un error en el producto de Alpha, un atacante puede ganar una pequeña cantidad de dinero a través de esto.
- Repita hasta que ese número cruce 7 números.
- En ese momento, Alpha Homora tenía una gran deuda con IronBank, pero, por supuesto, el deudor ya se estaba escapando.
- Lavó dinero a través de Tornado Cash y devolvió 1000 ETH a Alpha and Cream.
Nota : Esto no hace que los prestamistas de Cream pierdan sus activos directamente, sino que incurren en una enorme deuda con Alpha Homora.
¿Quién es la víctima?
Cream y Alpha, entonces, ¿quién es la víctima?
Las partes involucradas en el ataque incluyen:
- Cream v2 : Acordó la integración intensiva a nivel de contrato con Alpha Homora v2.
- Alpha Homora v2 : Acuerde a nivel de contrato tomar prestados activos de Cream v2 sin garantía.
- Prestamista en Cream : cuando la comunidad acepta un acuerdo de cooperación intensiva entre Cream y Alpha, significa que el prestamista no solo presta a los usuarios de Cream sino también a los usuarios de Alpha Homora v2.
- Prestatario en Alpha : similar al prestatario en Alpha, no solo toma prestado de Alpha sino también de Cream v2. El atacante pertenece a este grupo y se clasifica como prestatario con malas intenciones.
![Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi Descifrado de ataques en Alpha y Cream: cuando se pone a prueba la colaboración DeFi]()
En este momento:
- En un nivel fundamental : Alpha Homora debe Cream v2.
- Mirando más profundo : los activos de los prestamistas en Cream están siendo tomados prestados por el partido con malas intenciones.
Con el análisis anterior, Alpha debería ser la parte que compense el daño de Cream. Sin embargo, desde una perspectiva técnica, Cream es la parte responsable de asegurar los activos del prestamista. Entonces Alpha puede renunciar por completo a la responsabilidad y cancelar la cooperación, dejando esa deuda incobrable a los usuarios de Cream.
Por supuesto, con la reputación y el éxito del presente, la capacidad de Alpha para hacer esto es muy baja. Pero el ataque destacó un problema existente con la colaboración entre proyectos en DeFi.
Consecuencia
Lo siguiente interesante es que a pesar de que el ataque se llevó a cabo a través del contrato de Alpha, fue Cream quien sufrió más. Los AUM (activos bajo administración) de Cream se redujeron de 700 millones a 200 millones en solo 1 día y el precio del token cayó un 30 %. En contraste, el AUM de Alpha solo disminuyó en un 10% y la venta de tokens fue insignificante.
La causa de esta paradoja puede deberse a:
- Cream fue el primero en salir a la luz, por lo que las ventas de pánico tuvieron un fuerte impacto en ellos.
- Los prestamistas de Cream se dieron cuenta de que eran los que más sufrían (aparte de la caída en los precios de los tokens, los usuarios de Alpha no sufrieron casi nada).
Prestar a un mercado con apalancamiento x9 era demasiado arriesgado incluso antes del ataque, y los prestamistas de Cream son cada vez más conscientes de ello.
Lección
Estos ataques han demostrado que DeFi aún es muy joven en la actualidad y el riesgo es grande para los usuarios. La auditoría lleva mucho tiempo y es costosa e incluso después de que se realiza la auditoría, si el producto no coincide con el sabor, todo fallará.
Alpha auditó dos veces y aun así fue pirateado, el ataque fue tan complejo que los desarrolladores e investigadores tardaron horas en comprender la naturaleza del problema.
La semana pasada yDAI (la bóveda de 1 Yearn) fue pirateada, el equipo de desarrollo ideó una solución para abrir la tesorería para compensar a todos por el daño. Sin embargo, con Alpha, el mercado que acepta sus tokens como deuda es demasiado pequeño, por lo que si Alpha quiere compensar, tendrá que hacer un acuerdo por separado con los prestamistas.
A partir de los ataques anteriores, se necesitarán muchas soluciones para garantizar la seguridad tanto de los proyectos como de los usuarios. Algunas sugerencias incluyen:
- Realice pruebas automatizadas y compare continuamente y garantice la corrección del algoritmo.
- Scale TVL lentamente garantiza la seguridad en cada etapa para minimizar el daño lo más bajo posible.
Epílogo
La línea entre riesgo y efectividad se probará cada vez más, y cada ataque es una lección para que DeFi madure.
Para los propios inversores, antes de participar en un proyecto, la asignación adecuada de capital y tomarse el tiempo para comprender el sistema es un requisito previo. Además, ser testigo de la decisión y la acción del proyecto después de ser atacado también es una buena prueba para ver si el equipo de desarrollo realmente siente pasión por su producto.
“La rentabilidad va de la mano del riesgo”
Enlace de referencia: https://defiweekly.substack.com/p/efab8b4a-5b1d-4d87-8a64-913070ec328f