WEB3DEV

Cover image for Uma Análise do Ataque à Euler Finance
Paulo Gio
Paulo Gio

Posted on

Uma Análise do Ataque à Euler Finance

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*lIs9lv3rqO0hrMX5g33jyw.png

Em 13 de março de 2023, o projeto de empréstimos Euler Finance, baseado na blockchain Ethereum, foi alvo de um ataque no qual o atacante obteve um lucro de aproximadamente 200 milhões de dólares. A equipe de segurança SlowMist interveio prontamente e analisou a situação, compartilhando os resultados da seguinte forma:

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*2-XoTQxLbR1EXQpArJCSkA.png

https://twitter.com/SlowMist_Team/status/1635230255878373377

Informações de Contexto

A Euler Finance é um protocolo de empréstimo não custodial e não permissionado na Ethereum, que permite aos usuários ganhar juros ou proteger-se contra a volatilidade de mercado com seus ativos de criptomoedas.

Quando os usuários depositam garantias na Euler Finance, eles recebem um EToken correspondente como prova, e o resgate subsequente das garantias e o empréstimo são realizados por meio do EToken. O design do EToken permite que os usuários peguem emprestado mais ativos e aumentem suas dívidas cunhando novos EToken e utilizando-os diretamente como garantia, ou seja, pegando emprestado de si mesmos com alavancagem em camadas.

O mecanismo de liquidação suave da Euler permite que os liquidantes ajudem os devedores a pagar suas dívidas, com flexibilidade, em vez de estarem limitados a coeficientes fixos.

Os seguintes endereços estão relacionados ao ataque:

Endereço da EOA (Conta de Propriedade Externa) do Atacante 1: 0x5f259d0b76665c337c6104145894f4d1d2758b8c

Endereço da EOA do Atacante 2: 0xb2698c2d99ad2c302a95a8db26b08d17a77cedd4

Endereços de Contrato do Ataque: https://etherscan.io/address/0xeBC29199C817Dc47BA12E3F86102564D640CBf99 https://etherscan.io/address/0x036cec1a199234fC02f72d29e596a09440825f1C

Transações do Ataque: https://etherscan.io/tx/0xc310a0affe2169d1f6feec1c63dbc7f7c62a887fa48795d327d4d2da2d6b111d https://etherscan.io/tx/0x71a908be0bef6174bccc3d493becdfd28395d78898e355d451cb52f7bac38617 https://etherscan.io/tx/0x62bd3d31a7b75c098ccf28bc4d4af8c4a191b4b9e451fab4232258079e8b18c4 https://etherscan.io/tx/0x465a6780145f1efe3ab52f94c006065575712d2003d83d85481f3d110ed131d9 https://etherscan.io/tx/0x3097830e9921e4063d334acb82f6a79374f76f0b1a8f857e89b89bc58df1f311 https://etherscan.io/tx/0x47ac3527d02e6b9631c77fad1cdee7bfa77a8a7bfd4880dccbda5146ace4088f

Causa Raiz

Houve dois motivos críticos por trás do ataque:

Primeiramente, a falha em verificar se o usuário estava em um estado de liquidação após doar fundos para o endereço de reserva resultou no acionamento direto do mecanismo de liquidação suave.

Em segundo lugar, o fator de saúde do devedor cai abaixo de 1 quando a lógica de liquidação suave é acionada devido à alta alavancagem. Isso permite que o lucro do liquidante cubra totalmente a dívida, pois o valor da garantia obtido após a liquidação é maior do que o valor da dívida. Assim, o liquidante pode extrair com sucesso os fundos obtidos sem a necessidade de qualquer garantia adicional, passando facilmente na verificação de saúde (checkLiquidity).

Processo de Ataque

Esta seção analisa a transação de ataque com hash 0xc310a0af, com outras técnicas de ataque permanecendo consistentes:

1.O atacante pegou emprestado 30.000.000 DAI por meio de um empréstimo relâmpago da Aave e criou dois contratos de subataque (0x583c21 e 0xA0b3ee) em preparação para ataques subsequentes.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*m42cwvMIjlhOacno6EjBhA.png

2.O atacante depositou 20.000.000 DAI na Euler Finance por meio da função de depósito e obteve 19.568.124,3 eDAI como tokens de garantia.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*5rDHvgLeHiRVMvBaPFemgQ.png

3.O atacante chamou a função mint (auto-empréstimo) para pegar emprestado 195.681.243 eDAI e 200.000.000 tokens de dívida (dDAI).

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*E4FRobYyk5Xf_pMupE1seg.png

4.Imediatamente depois, o atacante chamou a função repay para pagar os 10.000.000 restantes de DAI. Isso foi feito para reduzir a dívida e aumentar o valor da garantia em preparação para outra rodada de empréstimos.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*V7Xz65O6r8QSldBJPG41Kw.png

5.O atacante então chamou novamente a função mint (auto-empréstimo) para uma segunda rodada de empréstimos, pegando emprestado 195.681.243 eDAI e 200.000.000 dDAI. Neste ponto, a conta possuía aproximadamente 410.930.612 eDAI e 390.000.000 dDAI.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*2NP9yNHzwJRWYk-N6DlU6g.png

6.O atacante então chamou a função donateToReserves para doar 100.000.000 eDAI para o endereço de reserva. Neste ponto, a conta possuía 310.930.612 eDAI e 390.000.000 dDAI, colocando-a em um estado de liquidação. No entanto, a função donateToReserves não verificou o fator de saúde da conta.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*twF9CsmTGO92P2ViAhPdwQ.png

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*PGWBf8JuRXFUQtriTLVTKA.png

7.O atacante chamou a função liquidation usando outro contrato de subataque (0xA0b3ee) para liquidar a conta (0x583c21), que estava em estado de liquidação no passo anterior.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*7CRZY3zaRi6w7msgFSkewg.png

Durante o processo de liquidação, o atacante transferiu a dívida de 259.319.058 dDAI da conta 0x583c21 para 0xA0b3ee e obteve 310.930.612 eDAI da conta.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*UTabC-vhNXqgu_Qn5z25TQ.png

É evidente que o liquidante assume apenas uma pequena quantidade de dívida, mas pode obter a maior parte da garantia. Isso ocorre devido ao mecanismo de liquidação suave da Euler Finance: quando o liquidante inicia o processo de liquidação, um desconto é calculado com base no fator de saúde do devedor. Como resultado desse mecanismo, quanto menor o fator de saúde, maior o desconto e mais garantia pode ser transferida. No final, o liquidante só precisa cobrir sua própria dívida para concluir esse ataque.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*XP-Zib_DQ7Y8TP45VePg7g.png

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*hznYckRg7eUJl7tB8qDuRQ.png

Como a quantidade de garantia obtida pela conta 0xA0b3ee após a liquidação era maior do que a quantidade de dívida, a conta conseguiu passar na verificação de liquidação com sucesso.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*lzdsvGGrCFA_tPiTHIe6Ew.png

8.Por fim, o atacante chamou a função withdraw para sacar os fundos obtidos da liquidação anterior e pagar o lucro obtido com o empréstimo relâmpago.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*Nf1e84sTY8Llr2jv3Sjsog.png

Análise da Cadeia pelo MistTrack

No momento da escrita, 100 ETH foram transferidos pelo atacante para a Tornado Cash.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*EqCg7WVLFHS8FHb1u3qFfg.png

Os fundos restantes estão na conta do atacante.

Aqui estão os detalhes: (Observação: Os preços são a partir das 10:00 UTC em 14 de março de 2023)

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*C_VRCyv_lDkIn6c_zZIgKg.png

Vale ressaltar que houve um total de 6 transações de ataque nesse ataque, sendo que a primeira transação de ataque foi iniciada pelo endereço EOA do atacante 1, e todas as outras transações de ataque foram iniciadas pelo endereço EOA do atacante 2.

Aqui está a linha do tempo das 6 transações de ataque:

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*JPfrwwXnXeMkhX72uTrN1A.png

Em 13 de março de 2023, às 11:38:11 UTC, o endereço EOA do atacante 1 retirou 8.877.507,34 DAI para o endereço EOA do atacante 2.

Em 13 de março de 2023, às 12:08:35 UTC, o endereço EOA do atacante 1 iniciou uma transação de mensagem na cadeia, alegando ser um bot de MEV que superou a primeira transação de ataque iniciada pelo endereço EOA do atacante 2 e tentou superar outras transações de ataque, mas falhou. Infelizmente, o contrato de ataque criado pelo bot só pôde fazer saques para o endereço de lucro do endereço EOA do atacante 2.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*VltG7JLvWkIKgSWugHr3Zw.png

De acordo com a equipe de análise na cadeia da MistTrack, a origem das taxas utilizadas pelo endereço EOA do atacante 1 foi rastreada até um endereço de hacker que havia realizado anteriormente um ataque de empréstimo relâmpago no projeto EPMAX, na Binance Smart Chain, roubando um total de 346.399,28 USDT.

Após o ataque, o endereço do hacker do ataque EPMAX passou para a rede ETH por meio do cBridge e transferiu os lucros para a Tornado Cash. As ferramentas de plataforma usadas pelo hacker do ataque EPMAX incluem Multichain, FixedFloat, cBridge, 1inch e KyberSwap.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*QxkJQLm4fvTZWQ4NkWx3Pg.png

As taxas utilizadas pelo endereço EOA do atacante 2 também foram rastreadas até a Tornado Cash.

https://miro.medium.com/v2/resize:fit:1100/format:webp/1*X0CGt3a_GoYhDe7o6-L5CA.png

Resumo

Após uma análise cuidadosa, fica evidente que não há problema em examinar a operação "donate" isoladamente sem verificar a liquidez do usuário doador. Quando um usuário está em estado de liquidação após a doação, é inevitável que bots de arbitragem realizem os procedimentos de liquidação necessários. Além disso, focar exclusivamente nas características da liquidação suave pode ajudar a aliviar cenários de liquidação excessiva ou insuficiente. Nos casos de liquidação normal, o liquidante é obrigado a fornecer garantia para evitar uma falha na verificação de liquidez após concluir o processo de liquidação.

No entanto, quando a operação "donate" é combinada com a liquidação suave, ocorre uma reação diferente. Os atacantes podem usar alavancagem (auto-empréstimo) e a funcionalidade de doação para reduzir seu fator de saúde abaixo de 1, o que leva diretamente os liquidantes a serem capazes de cobrir suas dívidas com lucros após a conclusão da liquidação.

A razão principal para esse ataque é a ausência de verificações de liquidez em funções críticas que envolvem fundos de usuários, o que, combinado com um mecanismo de liquidação que atualiza dinamicamente os descontos, cria oportunidades lucrativas de arbitragem para os atacantes drenarem uma grande quantidade de garantias sem a necessidade de garantia ou pagamento de dívidas. Como resultado, a Equipe de Segurança da SlowMist recomenda que os protocolos de empréstimo incorporem verificações de saúde necessárias em funções que envolvem fundos de usuários, ao mesmo tempo em que consideram os riscos de segurança que podem surgir ao combinar diferentes módulos. Isso permitirá o design de modelos econômicos seguros e viáveis que efetivamente mitiguem esses ataques no futuro.

Sobre a SlowMist

A SlowMist é uma empresa de segurança blockchain estabelecida em janeiro de 2018. A empresa foi iniciada por uma equipe com mais de dez anos de experiência em segurança de rede, com o objetivo de se tornar uma força global. Nosso objetivo é tornar o ecossistema blockchain o mais seguro possível para todos. Agora somos uma renomada empresa internacional de segurança blockchain que trabalhou em diversos projetos conhecidos, como Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, O3Swap, etc.

Website: https://www.slowmist.com

Twitter: https://twitter.com/SlowMist_Team

Github: https://github.com/slowmist/

Artigo original publicado por SlowMist. Traduzido por Paulinho Giovannini.

Top comments (0)