Análisis en profundidad del incidente de $9M en activos de Yearn hackeados: desde vulnerabilidades en el protocolo hasta la evaporación del valor en dólares

El 1 de diciembre de 2025, el protocolo Earn experimentó un ataque compuesto multicapa bien planificado en la historia de DeFi, que finalmente resultó en la pérdida de aproximadamente 9 millones de dólares en activos de usuarios. No se trata de un simple punto de explotación, sino de una destrucción sistemática por parte de atacantes que usan préstamos flash para apalancar fondos, romper los mecanismos de protección de protocolos capa por capa, crear tokens LP relacionados con yETH indefinidamente y, finalmente, agotar el pool. Este incidente advierte una vez más a toda la industria: el riesgo de seguridad de los protocolos DeFi no radica en una sola vulnerabilidad, sino en la superposición de múltiples fallos; este es el modo de ataque más difícil de defender en la industria.

Resumen del evento: Cómo los préstamos flash pueden ser una pesadilla para ataques en varias fases

La estrategia de financiación del atacante puede parecer ordinaria, pero sienta las bases para una serie de operaciones en cadena posteriores. Lanzaron préstamos flash de los protocolos Balancer y Aave al mismo tiempo, y prestaron un gran número de derivados de ETH como wstETH, rETH, WETH, ETHx y cbETH en un momento dado. Estos activos no entraron directamente en la transacción, sino que se distribuyeron cuidadosamente: 100 de 1.100 ETH se enviaron a Tornado. Efectivo para mezclar, un paso cuyo verdadero propósito era ocultar el origen de los fondos y allanar el camino para futuras operaciones de “blanqueamiento”.

Tras completar la mezcla, el atacante retiró 100 ETH 0x3e8e7533dcf69c698Cf806C3DB22f7f10B9B0b97 la dirección maliciosa del contrato y activó su función de respaldo. En esta retirada encubierta, todos los activos prestados se convirtieron en tokens LP para el pool de stableswap ponderado yETH, equivalente a comprar “certificados de acciones” para este pool. A simple vista, es una inyección de liquidez ordinaria, pero en realidad es la preparación final para una exquisita “técnica de vaciado de piscinas”.

Tres vulnerabilidades principales: una combinación fatal de pérdida de precisión, reducción de ingresos y cero inicialización de suministro

Vulnerabilidad de la Capa 1: pérdida de precisión y manipulación del estado sin coste

En el núcleo técnico de todo el ataque hay un fallo de código aparentemente trivial:remove_liquidity función no provoca un cortocircuito en la cantidad cero。

El primer movimiento del atacante es crear deliberadamente un desequilibrio extremo de activos en el pool. Llamó repetidamente a la función add_liquidity (añadir liquidez), pero deliberadamente omitió la inyección del índice 3 (rETH), índice 6 (wOETH) e índice 7 (mETH), ampliando artificialmente la brecha de ratio entre estos tres activos y otros activos. Posteriormente, inyectó unilateralmente una enorme cantidad de rETH, ampliando aún más el desequilibrio.

En este estado de pool extremadamente desequilibrado, el atacante llama a remove_liquidity, pero introduce un parámetro de retirada de 0. Según la lógica convencional, retirar 0 tokens debería devolver directamente y no debería tener ningún cambio de estado. Pero el contrato pool.vy no hace esto: sigue ejecutando un bucle de cálculo completo de vb_prod (producto de balance virtual).

En el entorno matemático de un desequilibrio extremo de peso, _pow_down función (redondeo hacia abajo) produce una pérdida significativa de precisión. El contrato calcula incorrectamente un valor de vb_prod pequeño y escribe este valor manipulado al estado global packed_pool_vb. Básicamente, el atacante manipuló con éxito el valor contable de todo el pool mediante una operación de “coste cero” (no se transfirieron tokens).

Lagunas legales de la capa 2: desinversión de ingresos y erosión de acciones

La segunda capa de vulnerabilidades está más oculta. Cuando un atacante llama a update_rates función, se activa la lógica interna _update_supply. Como vb_prod había sido suprimido de forma maliciosa, el sistema creó una falsa percepción de que el valor total del fondo se había reducido drásticamente. Para equilibrar el libro, el contrato quema automáticamente una gran cantidad de tokens LP que posee el contrato de staking.

El atacante realizó con precisión las operaciones de arbitraje antes y después de la actualización del tipo de cambio. Cada call update_rates actualizar el tipo de cambio de un activo específico (por ejemplo, wOETH, mETH), y luego inmediatamente llamar remove_liquidity retirar el activo. Dado que se destruyeron un gran número de acciones del contrato de staking, relativamente hablando, la proporción de acciones de LP en manos del atacante aumentó pasivamente. Al repetir este ciclo de “actualización-extracción-quema”, el atacante extraía el saldo real de wOETH y mETH del pool paso a paso, mientras empujaba el suministro total del pool hasta el peligroso límite de valor cero.

Vulnerabilidad de la capa 3: el punto de inflexión de la acuñación ilimitada de suministro cero

Tras una serie de operaciones en las dos primeras etapas, el depósito se ha vaciado: el suministro total está cerca de cero y el balance de wOETH y mETH es extremadamente bajo. En este punto, el atacante asesta el golpe fatal: llama add_liquidity con los parámetros inyectados [1, 1, 1, 1, 1, 9] — es decir, los primeros siete activos inyectan cada uno 1 wei (la unidad más pequeña), y el octavo (mETH) inyecta 9 wei.

Esta operación aparentemente absurda provocó un colapso computacional del contrato en un momento crítico cuando la piscina estaba a punto de ser destruida. La fórmula iterativa de _calc_supply falló al tratar con el valor mínimo, y el contrato se acuñó incorrectamente235.443 tokens yETH LP。 Es equivalente a crear millones de dólares en activos falsos de la nada.

Explicación detallada de las cuatro etapas del ataque: desde un desequilibrio extremo hasta una acuñación infinita

Fase 1: Preparación de fondos e inicialización del estado del fondo

• Tomar prestados múltiples derivados de ETH de Balancer y Aave
• Disimular el origen de los fondos a través de Tornado. Mezcla de efectivo
• Convertir todos los fondos mixtos y activos prestados en tokens yETH LP

Etapa 2: Fabricación artificial de un desequilibrio extremo

• Inyecciones de liquidez unilaterales repetidas, saltándose tokens específicos (rETH, wOETH, mETH)
• La inyección unilateral de grandes cantidades de rETH amplía aún más el desequilibrio
• Esta etapa crea condiciones matemáticas para la pérdida de precisión

Fase 3: Reducción de ingresos y expansión de acciones

• Desencadenar la pérdida del estado de precisión por remove_liquidity (0).
• Llamar update_rates actualizar el tipo de cambio, lo que resulta en la destrucción de los tokens LP del contrato de staking
• Operaciones repetidas de arbitraje para drenar saldos de wOETH y mETH
• El suministro total de la reserva se reduce a 0

Fase 4: Cero suministro de acuñación ilimitada

• Llamar add_liquidity cuando la piscina esté a punto de ser destruida ([1,1,1,1,1,1,1,9])
• El cálculo del _calc_supply del contrato se colapsó, acuñando incorrectamente 235.443 fichas LP
• El atacante completa el intercambio de activos mediante Intercambio y Canje
• Devolver préstamos flash, intercambiar los activos adquiridos por activos líquidos como Bitcoin y dólares estadounidenses para su liquidación

Seguimiento de fondos y trayectoria de liquidación: pérdida de valor de yETH a USD

La comedia negra definitiva de este ataque reside en la cadena de escape de fondos. Los 235.443 tokens LP obtenidos por los atacantes fueron intercambiados gradualmente por ETH y stablecoins a través de una serie de operaciones de intercambio. Estos activos se intercambian posteriormente por formas más ocultas como Bitcoin a través de pares de trading DEX, y finalmente millones de dólares en activos se intercambian por efectivo o Bitcoin a través de plataformas de venta extratera. Durante todo el proceso, 9 millones de dólares de fondos de los usuarios se transfirieron abiertamente del saldo del protocolo a la cartera del atacante en la cadena, y luego se intercambiaron gradualmente por dólares estadounidenses, Bitcoin, etc., y finalmente escaparon.

Implicaciones en la industria: Cómo los protocolos DeFi pueden proteger contra ataques complejos de composición

Hay tres lecciones clave de este incidente:

Lección 1: Fortalecer la verificación de escenas en los bordes Los protocolos DeFi deben realizar comprobaciones lógicas estrictas en escenarios límite como “cantidad cero” y “desequilibrio extremo”. remove_liquidity debería devolver tan pronto como se reciba el parámetro 0, en lugar de ejecutar un bucle de cálculo completo. Este tipo de “procesamiento de cortocircuito” puede parecer sencillo, pero puede prevenir eficazmente la posibilidad de manipulación del estado.

Lección 2: Optimizar la lógica de cálculo de precisión _pow_down y otras funciones que impliquen cálculos proporcionales extremos deben introducir mecanismos de protección. Considera usar una biblioteca de procesamiento numérico más sofisticada, añadir detección de desbordamiento intermedia o usar diferentes ramas de algoritmos en escenarios extremos. Históricamente, el protocolo Balancer ha sido atacado por problemas similares de precisión, lo cual es una lección del pasado.

Lección 3: Establecer monitorización multidimensional de anomalías Es necesario construir un sistema de monitorización en tiempo real que proporcione alerta temprana para las siguientes operaciones:

• La alta frecuencia de inyección unilateral de liquidez conduce a un desequilibrio extremo en el pool
• Fluctuaciones anormales del tipo de cambio y eventos automáticos de combustión
• Frecuencia inusual de transacciones de cantidad cero y operaciones de valor mínimo
• Pool Total Supply fluctúa bruscamente en un corto periodo de tiempo

Para todo el ecosistema DeFi, este incidente demuestra una verdad profunda:La seguridad no consiste en corregir una vulnerabilidad, sino en prevenir sistemáticamente la combinación de múltiples fallos。 Los desarrolladores de protocolos deben analizar la lógica del código desde una perspectiva de proceso completo y no dejar pasar ningún defecto de diseño aparentemente “inofensivo”. Al mismo tiempo, la industria necesita reforzar las capacidades de seguimiento y congelación on-chain de los flujos de capital de los atacantes, y mejorar las capacidades de protección general mediante listas negras de DEX y el control de riesgos de plataformas OTC. El hackeo de Yearn no es el final, pero debería ser un catalizador para la evolución de la seguridad de toda la industria.