Em 13 de março de 2023, nosso sistema detectou que o pool de empréstimos da Euler Finance sofreu um ataque de flash loan, resultando em perdas de $197 milhões. Primeiro alertamos a comunidade e, em seguida, fornecemos uma análise para ajudar a identificar a causa raiz.
1/ @eulerfinance is attacked. The root cause is due to the lack of liquidity check in the function donateToReserves()https://t.co/stWtPWK900
— BlockSec (@BlockSecTeam) March 13, 2023
See the detailed attack steps below. https://t.co/bm10OJHiXu pic.twitter.com/TDbYuzVWHe
A causa raiz deste incidente é a falta de verificação de insolvência na função donateToReserves(). Especificamente, o contrato vulnerável fornece uma funcionalidade para que os usuários doem seu colateral ao protocolo sem verificar se a posição do usuário era solvente. Pior ainda, para se livrar dessa posição problemática, o protocolo oferecia um grande desconto para que os liquidadores pagassem menos dívida para liquidar essa posição. O atacante criou uma posição grande e tornou essa posição insolvente explorando essa funcionalidade. Em seguida, ele foi capaz de comprar seu colateral com desconto para obter lucro.
Contexto
Visão Geral da Euler Finance
A Euler Finance é um protocolo de empréstimos na Ethereum que permite aos usuários emprestar e tomar emprestado tokens específicos. Quando os credores depositam no pool de liquidez da Euler, uma quantidade correspondente de ETokens (tokens ERC20 com rendimento de juros) é cunhada e enviada a eles. Esses ETokens podem ser resgatados pelos ativos subjacentes depositados.
Por outro lado, os tomadores de empréstimo que recebem liquidez recebem DTokens. Esses DTokens são compatíveis com ERC20 e impedem que os detentores os queimem de forma independente. Especificamente, em vez de permitir que os tokens sejam enviados a qualquer pessoa, eles podem ser tomados por qualquer pessoa, mas aceitá-los requer aprovação. Em termos do ativo subjacente, os tomadores de empréstimo são responsáveis pelo pagamento de juros sobre seus empréstimos, e uma parte desses juros é usada para cobrir dívidas incobráveis no protocolo.
Os mecanismos de empréstimo alavancado (também conhecido como auto-empréstimo) e de liquidação suave da Euler Finance são dois conceitos-chave que nos ajudam a entender melhor a causa deste ataque.
Empréstimo Alavancado
A Euler Finance fornece um recurso de empréstimo alavancado, que permite aos usuários simular uma estratégia de empréstimo recursivo. Em termos simples, os usuários podem depositar colateral e cunhar ETokens, que podem então ser usados como colateral para tomar emprestado mais ETokens. O contrato também cunhará uma quantidade correspondente de dTokens como tokens de dívida. A saúde da posição do usuário é calculada com base nos valores dos ETokens e dTokens. De acordo com a documentação da Euler Finance, os usuários podem alavancar até 19x. O recurso de empréstimo alavancado desempenhou um papel crucial neste incidente. Sem a assistência desse recurso, o atacante não teria sido capaz de lucrar. Por meio do empréstimo alavancado, o atacante amplificou o tamanho de sua posição para quase 11x dos fundos iniciais obtidos com o flash loan.
Liquidação Suave
Conforme descrito no whitepaper da Euler Finance, o mecanismo de liquidação suave permite que os liquidadores ajudem a parte liquidada a pagar sua dívida de forma flexível, em vez de ser restrito a um coeficiente fixo para liquidação, como adotado por protocolos como Compound e Aave. A liquidação suave significa que quanto menor a saúde de uma posição, mais colateral é elegível para liquidação — até 75% no caso de dívida incobrável, com base nos dados deste incidente. A liquidação de colateral com desconto substancial, portanto, permitiu que o atacante quitasse o flash loan e garantisse um lucro.
Análise de Vulnerabilidade
A principal vulnerabilidade, ou seja, a falta de uma verificação de insolvência, existe dentro da função donateToReserves(), que é usada pelos usuários para transferir ETokens de suas posições para a reserva do protocolo como doações. Para usuários regulares, normalmente não há incentivo ou motivação para realizar tal ação. De fato, a vulnerabilidade reside no fato de que a função donateToReserves() não realiza uma verificação de saúde ao transferir ETokens das posições dos usuários. Isso permite que atacantes doem diretamente os ETokens da posição grande criada por meio de empréstimo alavancado, fazendo com que a saúde da posição caia abaixo de 100% e resultando em dívida incobrável.

De acordo com o design, a Euler Finance usa um fator de fechamento dinâmico para "liquidar suavemente" as posições. Em resumo, quanto menos saudável for uma posição, maior a proporção do colateral nessa posição que pode ser liquidada. No caso de dívida incobrável, o percentual de liquidação pode chegar a 75% do colateral dentro da posição (conforme calculado com base na transação de ataque real). Como resultado, a quantidade significativa de colateral com desconto que é liquidada permite que o atacante reembolse o flash loan e obtenha lucros.
Análise do Ataque
Existem múltiplas transações de ataque visando diferentes pools:
- 0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d (DAI)
- 0x71a908be0bef6174bccc3d493becdfd28395d8898e355d451cb52f7bac38617 (WBTC)
- 0x62bd3d31a7b75c098ccf28bc4d4af8c4a191b4b9e451fab4232258079e8b18c4 (wstETH)
- 0x465a6780145f1efe3ab52f94c006065575712d2003d83d85481f3d110ed13d9 (USDC)
- 0x3097830e9921e4063d334acb82f6a79374f76f0b1a8f857e89b89bc58df1f311 (stETH)
- 0x47ac3527d02e6b9631c77fad1cdee7bfa77a8a7bfd4880dccbda5146ace4088f (WETH)
As etapas do ataque são as seguintes (tomando a primeira transação de ataque como exemplo):
- O atacante tomou emprestado 30M DAI na AAVE via flashloan.
- O atacante depositou 20M DAI e recebeu de volta 20M eDAI.
- Como a Euler Finance fornece a capacidade de empréstimo alavancado, o atacante pode cunhar 195M eDAI e 200M dDAI. Agora o atacante possui 215M eDAI e 200M dDAI.
- Continuando acima. 10M de dívida foi paga para que o atacante pudesse cunhar mais eDAI. Agora o atacante possui 215M eDAI e 190M dDAI.
- O passo 3 foi repetido. Agora o atacante possui 410M eDAI e 390M dDAI.
- O atacante invocou a função donateToReserve para doar 100M eDAI. No entanto, durante esse processo, o fator de saúde do atacante não foi verificado. Nesse caso, a posição agora pode ser liquidada (310M eDAI vs. 390M dDAI), o que deixa a chance de obter lucro.
- O atacante liquidou a posição usando outro contrato de endereço como liquidador (0xa0b3...). O liquidador (0xa0b3...) recebeu 310M eDAI e 259M dDAI.
- O atacante queimou 38,9M eDAI para retirar 38,9M DAI (não é possível retirar mais devido às verificações de insolvência) na posição do liquidador (0xa0b3...).
- O atacante reembolsou o flashloan.
As etapas-chave do ataque 2-7 estão marcadas no rastreamento da transação.

Resumo
Este foi o maior hack de 2023, com um recorde de $197 milhões em fundos roubados por um argentino de 20 anos chamado Federico Jaime, que forneceu à mídia "uma narrativa tortuosa, às vezes confusa e até contraditória". No entanto, "todos os fundos recuperáveis" foram posteriormente restaurados ao endereço do tesouro da Euler Finance. Porém, uma pequena parte (cerca de $200K) foi "inadvertidamente" enviada ao Grupo Lazarus — um suposto sindicato criminoso norte-coreano patrocinado pelo Estado e sancionado pelo Tesouro dos EUA. Você pode consultar esses links, ou seja, link2 e link2, para a história detalhada e interessante.
A causa raiz deste incidente foi a falta de verificações de insolvência, o que serve como uma lição. De fato, para um protocolo de empréstimos, é crucial avaliar se as verificações de saúde da posição devem ser implementadas para quaisquer procedimentos que possam impactar as posições dos usuários. Além disso, as equipes de projeto devem monitorar proativamente seu protocolo de empréstimos em busca de liquidações significativas e estabelecer sistemas de alerta eficazes para detectar e responder prontamente a tais eventos.
Leia outros artigos desta série:
- Introdução: Os Dez Maiores Incidentes de Segurança "Impressionantes" de 2023
- #1: Colhendo Bots de MEV Explorando Vulnerabilidades no Flashbots Relay
- #3: Incidente KyberSwap: Exploração Magistral de Erros de Arredondamento com Cálculos Extremamente Sutis
- #4: Incidente Curve: Erro de Compilador Produz Bytecode Defeituoso a partir de Código Fonte Inofensivo
- #5: Platypus Finance: Sobrevivendo a Três Ataques com uma Pitada de Sorte
- #6: Incidente Hundred Finance: Catalisando a Onda de Explorações Relacionadas a Precisão em Protocolos Bifurcados Vulneráveis
- #7: Incidente ParaSpace: Uma Corrida Contra o Tempo para Frustrar o Ataque Mais Crítico da Indústria até o Momento
- #8: Incidente SushiSwap: Uma Tentativa de Resgate Desajeitada Leva a uma Série de Ataques Imitadores
- #9: MEV Bot 0xd61492: De Predador a Presa em uma Exploração Engenhosa
- #10: Incidente ThirdWeb: Incompatibilidade Entre Módulos Confiáveis Expõe Vulnerabilidade



