Análise aprofundada do incidente de $9M em ativos da Yearn sendo roubados: desde vulnerabilidades no protocolo até a evaporação do valor em dólares

A 1 de dezembro de 2025, o protocolo Earn sofreu um ataque composto em múltiplas camadas bem planeado na história da DeFi, resultando na perda de aproximadamente 9 milhões de dólares em ativos de utilizadores. Isto não é um simples ponto único de exploração, mas uma destruição sistemática por atacantes que usam empréstimos flash para alavancar fundos, romper mecanismos de proteção de protocolo camada por camada, criar tokens LP relacionados com yETH indefinidamente e, eventualmente, esgotar o pool. Este incidente alerta mais uma vez toda a indústria: o risco de segurança dos protocolos DeFi não reside numa única vulnerabilidade, mas na sobreposição de múltiplas falhas – este é o modo de ataque mais difícil da indústria para se defender.

Visão Geral do Evento: Como os Empréstimos Instantâneos Podem Ser Invasores para Ataques em Múltiplas Fases

A estratégia de financiamento do atacante pode parecer comum, mas lança as bases para uma série de operações subsequentes em cadeia. Lançaram empréstimos flash dos protocolos Balancer e Aave ao mesmo tempo, e emprestaram um grande número de derivados de ETH como wstETH, rETH, WETH, ETHx e cbETH em simultâneo. Estes ativos não foram diretamente para a transação, mas foram cuidadosamente distribuídos: 100 de 1.100 ETH foram enviados para a Tornado. Dinheiro para mistura – um passo cujo verdadeiro propósito era mascarar a origem dos fundos e abrir caminho para operações subsequentes de “branqueamento”.

Após a mistura concluída, o atacante retirou 100 ETH 0x3e8e7533dcf69c698Cf806C3DB22f7f10B9B0b97 endereço do contrato malicioso e acionou a sua função de recurso. Nesta retirada encoberta, todos os ativos emprestados foram convertidos em tokens LP para o pool de stableswap ponderado em yETH – o equivalente a comprar “certificados de ações” para este pool. À primeira vista, trata-se de uma injeção de liquidez comum, mas na verdade é a preparação final para uma requintada “técnica de esvaziamento de poços”.

Três vulnerabilidades principais: uma combinação fatal de perda de precisão, redução de receitas e zero inicialização do fornecimento

Vulnerabilidade da Camada 1: perda de precisão e manipulação do estado sem custo

No cerne técnico de todo o ataque encontra-se uma falha de código aparentemente trivial:remove_liquidity função não faz curto-circuito na quantidade zero。

O primeiro movimento do atacante é criar deliberadamente um desequilíbrio extremo de ativos no pool. Ele chamou repetidamente a função add_liquidity (adicionar liquidez), mas ignorou deliberadamente a injeção do índice 3 (rETH), índice 6 (wOETH) e índice 7 (mETH), alargando artificialmente a diferença de rácio entre estes três ativos e outros ativos. Subsequentemente, injetou unilateralmente uma enorme quantidade de rETH, aumentando ainda mais o desequilíbrio.

Neste estado de pool extremamente desequilibrado, o atacante chama remove_liquidity, mas introduz um parâmetro de quantidade de retirada de 0. De acordo com a lógica convencional, retirar tokens 0 deveria devolver diretamente e não deveria ter quaisquer alterações de estado. Mas o contrato pool.vy não faz isto – continua a executar um ciclo completo de cálculo de vb_prod (produto de balanço virtual).

No ambiente matemático de desequilíbrio extremo de peso, _pow_down função (arredondar para baixo) provoca uma perda significativa de precisão. O contrato calcula incorretamente um valor de vb_prod pequeno e escreve esse valor adulterado no estado global packed_pool_vb. Essencialmente, o atacante manipulou com sucesso o valor contabilístico de todo o pool com uma operação de “custo zero” (nenhum token foi transferido).

Brechas da Camada 2: desinvestimento de receitas e erosão de ações

A segunda camada de vulnerabilidades é mais oculta. Quando um atacante chama update_rates função, esta desencadeia lógica interna _update_supply. Como vb_prod tinha sido suprimido maliciosamente, o sistema criou uma falsa perceção de que o valor total do fundo tinha diminuído drasticamente. Para equilibrar o livro, o contrato queima automaticamente uma grande quantidade de tokens LP detidos pelo contrato de staking.

O atacante realizou com precisão as operações de arbitragem antes e depois da atualização da taxa de câmbio. Cada call update_rates atualizar a taxa de câmbio de um ativo específico (por exemplo, wOETH, mETH), e depois chamar imediatamente remove_liquidity retirar o ativo. Como um grande número de ações do contrato de staking foi destruído, relativamente falando, a proporção de ações da LP nas mãos do atacante aumentou passivamente. Ao repetir este ciclo de “atualização-extração-queima”, o atacante extraía o equilíbrio real de wOETH e mETH no pool passo a passo, enquanto empurrava o Suprimento Total do pool para o perigoso limite de valor zero.

Vulnerabilidade da Camada 3: o ponto de viragem da cunhagem ilimitada de oferta zero

Após uma série de operações nas duas primeiras fases, o pool foi esvaziado: o fornecimento total está próximo de zero e o saldo de wOETH e mETH é extremamente baixo. Neste ponto, o atacante desfere o golpe fatal: chama add_liquidity com os parâmetros injetados [1, 1, 1, 1, 1, 9] – ou seja, os primeiros sete ativos injetam cada um 1 wei (a unidade mais pequena), e o oitavo (mETH) injeta 9 wei.

Esta operação aparentemente absurda desencadeou um colapso computacional do contrato num momento crítico, quando a piscina estava prestes a ser destruída. A fórmula iterativa de _calc_supply falhou ao lidar com o valor mínimo, e o contrato foi cunhado incorretamente235.443 tokens yETH LP。 É equivalente a criar milhões de dólares em ativos falsos do nada.

Explicação detalhada das quatro fases do ataque: do desequilíbrio extremo à cunhagem infinita

Fase 1: Preparação do fundo e inicialização do estado do pool

• Emprestar múltiplos derivados de ETH do Balancer e do Aave
• Disfarçar a origem dos fundos através do Tornado. Mistura de dinheiro
• Converter todos os fundos mistos e ativos emprestados em tokens yETH LP

Fase 2: Fabrico artificial de desequilíbrio extremo

• Injeções de liquidez unilaterais repetidas, saltando tokens específicos (rETH, wOETH, mETH)
• A injeção unilateral de grandes quantidades de rETH alarga ainda mais o desequilíbrio
• Esta etapa cria condições matemáticas para a perda de precisão

Fase 3: Redução de receitas e invasão de ações

• Desencadear a perda do estado de precisão por remove_liquidity (0).
• Call update_rates atualizar a taxa de câmbio, resultando na destruição dos tokens LP do contrato de staking
• Operações repetidas de arbitragem para drenar saldos wOETH e mETH
• A oferta total do pool é levada para 0

Fase 4: Oferta zero de cunhagem ilimitada

• Chamar add_liquidity quando a piscina estiver prestes a ser destruída ([1,1,1,1,1,1,9])
• O cálculo do _calc_supply do contrato colapsou, cunhando incorretamente 235.443 fichas LP
• O atacante conclui a troca de ativos através do Exchange and Redeem
• Reembolsar empréstimos flash, trocar os ativos adquiridos por ativos líquidos como Bitcoin e dólares americanos para liquidação

Rastreio de Fundos e Caminho de Liquidação: Perda de valor de yETH para USD

A comédia negra suprema deste ataque reside na cadeia de fuga de fundos. Os 235.443 tokens LP obtidos pelos atacantes foram gradualmente trocados por ETH e stablecoins através de uma série de operações de troca. Estes ativos são depois trocados por formas mais ocultáveis de ativos, como Bitcoin através de pares de negociação DEX, e, em última análise, milhões de dólares em ativos são trocados por dinheiro ou Bitcoin através de plataformas de balcão aberto (OTC). Durante todo o processo, 9 milhões de dólares em fundos dos utilizadores foram descaradamente transferidos do saldo do protocolo para a carteira do atacante na cadeia, e depois gradualmente trocados por dólares americanos, Bitcoin, etc., e finalmente escaparam.

Implicações na Indústria: Como os Protocolos DeFi Podem Proteger Contra Ataques de Composição Complexa

Há três lições principais deste incidente:

Lição 1: Reforçar a verificação da cena nas bordas Os protocolos DeFi devem realizar verificações lógicas rigorosas em cenários de borda como “quantidade zero” e “desequilíbrio extremo”. remove_liquidity deve devolver assim que o parâmetro 0 for recebido, em vez de executar um ciclo de cálculo completo. Este tipo de “processamento de curto-circuito” pode parecer simples, mas pode prevenir eficazmente a possibilidade de manipulação do estado.

Lição 2: Otimizar a lógica de cálculo de precisão _pow_down e outras funções que envolvem cálculos extremos proporcionais devem introduzir mecanismos de proteção. Considere usar uma biblioteca de processamento numérico mais sofisticada, adicionar deteção de overflow intermédio ou usar diferentes ramos de algoritmos em cenários extremos. Historicamente, o protocolo Balancer tem sido atacado devido a problemas semelhantes de precisão, o que é uma lição do passado.

Lição 3: Estabelecer monitorização multidimensional de anomalias É necessário construir um sistema de monitorização em tempo real para fornecer alerta precoce para as seguintes operações:

• Alta frequência de injeção unilateral de liquidez conduz a um desequilíbrio extremo no pool
• Flutuações anormais da taxa de câmbio e eventos automáticos de queima
• Frequência invulgar de transações de valor zero e operações de valor mínimo
• Pool Total Supply flutua acentuadamente num curto período de tempo

Para todo o ecossistema DeFi, este incidente prova uma verdade profunda:A segurança não se trata de corrigir uma vulnerabilidade, mas sim de prevenir sistematicamente a combinação de múltiplas falhas。 Os programadores de protocolos precisam de olhar para a lógica do código a partir de uma perspetiva de processo completo e não deixar passar quaisquer falhas aparentemente “inofensivas” de design. Ao mesmo tempo, a indústria precisa de reforçar as capacidades de rastreamento on-chain e congelamento dos fluxos de capitais dos atacantes, e melhorar as capacidades globais de proteção através de listas negras de DEX e controlo de risco de plataformas OTC. O hack Yearn não é o fim, mas deve ser um catalisador para a evolução da segurança de toda a indústria.