Em 15 de maio de 2024, a Sonne Finance sofreu um ataque à cadeia Optimism, resultando em perdas de até US$ 20 milhões. Após o ataque, o usuário do Twitter @tonyke_bot tuitou que protegeu os US$ 6,5 milhões restantes no pool de garantias da Sonne Finance (também conhecido como mercado, semelhante ao cToken in Compound) com cerca de US$ 100.

(https://twitter.com/tonyke_bot/status/1790547461611860182)

Ao descobrir o ataque, a equipe da Sonne Finance rapidamente interrompeu todos os mercados no Optimism e afirmou que os mercados na Base estavam seguros.

(https://twitter.com/SonneFinance/status/1790535383005966554)

Descrição breve do ataque

A Sonne Finance é uma protocolo de empréstimos descentralizada que bifurca o Composto V2 no Otimismo, fornecendo a indivíduos, instituições e protocolos acesso a serviços financeiros. O Sonne Finance protocolo agrega os ativos de token dos usuários para formar um pool de liquidez de empréstimo, fornecendo aos usuários um negócio de empréstimo semelhante ao de um banco. Como o Compound, protocolo participantes podem hipotecar seus tokens no pool de liquidez de empréstimo da Sonne Finance e obter o certificado soToken (o mesmo que cToken). SoToken é um certificado de ativos com juros, que gerará uma certa quantidade de renda à medida que o bloco progride, e também receberá incentivos de token SONE. Os participantes também podem pedir emprestado outros tokens do pool de ativos de empréstimo da Sonne com o soToken em suas mãos. Por exemplo, os participantes podem hipotecar uma certa quantidade de USDC para obter certificados soUSDC e, em seguida, emprestar WETH para posterior circulação. Os empréstimos hipotecários na Sonne Finance protocolo podem ser uma relação de muitos para muitos ativos. Durante o processo de empréstimo hipotecário, o protocolo calculará automaticamente o fator de saúde (Fator de Saúde) do endereço do participante. Quando o fator de saúde é inferior a 1, a hipoteca do endereço Produtos será suporte liquidação, e os síndicos também podem receber certas recompensas liquidação.

A relação entre o número de tokens subjacentes depositados pelos usuários e os soTokens cunhados está relacionada principalmente a uma variável chamada exchangeRate. Essa variável pode ser usada aproximadamente para indicar quanto vale cada token subjacente. A fórmula de cálculo para exchangeRate é a seguinte:

Na fórmula acima, totalCash refere-se ao número de tokens subjacentes detidos por soToken, totalBorrows refere-se ao número de tokens subjacentes emprestados em um determinado mercado, totalReserves refere-se ao valor total da reserva (incluindo os juros pagos pelo mutuário), totalSupply refere-se ao número de soToken cunhados.

Ao resgatar, os usuários podem especificar o número de tokens subjacentes que desejam resgatar, resgatarAmount, para calcular o número de soTokens que precisam ser destruídos, resgatarTokens. O método de cálculo é aproximadamente "redeemTokens = redeemAmount / exchangeRat". Observe que não há perda de precisão aqui. lidar com.

A essência deste ataque é que, quando o mercado (soToken) foi criado, o invasor realizou a primeira operação de casting de hipoteca e cunhou muito poucos soTokens com uma pequena quantidade de tokens subjacentes, resultando no valor "totalSupply" de soToken sendo muito pequeno. O invasor então explorou a vulnerabilidade da perda de precisão do contrato Solidity e, em seguida, enviou o token subjacente diretamente para o contrato soToken (soToken não será cunhado, o que significa que "totalSupply" permanece inalterado e "totalCash" se torna maior) em vez de staking + casting método para depósito o token subjacente. Tal operação faz com que a variável "totalCash" no contrato se torne maior, mas "totalSupply" permanece inalterada, fazendo com que a taxa de câmbio se torne maior. No final, quando o invasor resgata o token subjacente, o soToken que precisa ser destruído é menor do que o soToken cunhado durante a hipoteca. O invasor usa o soToken ganho para emprestar o token subjacente WETH e USDC a outros soTokens (como soWETH, soUSDC), e finalmente obtém lucros de até US$ 20 milhões.

Principais endereços envolvidos no ataque

Transações de preparação de ataque:

https://optimistic.etherscan.io/tx/0x45c0ccfd3ca1b4a937feebcb0f5a166c409c9e403070808835d41da40732db96

Ataque transações lucrativas:

https://optimistic.etherscan.io/tx/0x9312ae377d7ebdf3c7c3a86f80514878deb5df51aad38b6191d55db53e42b7f0

Atacar endereços relacionados EOA:

0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43

Endereço relacionado com o atacante (contrato):

0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8

0x02fa2625825917e9b1f8346a465de1bbc150c5b9

token subjacente(VELO Token V2):

0x9560e827af36c94d2ac33a39bce1fe78631088db

Contrato de vulnerabilidade (soVELO, semelhante ao cToken da Compound):

0xe3b81318b1b6776f0877c3770afddff97b9f5fe5

@tonyke_bot Transação de resgate do usuário no X:

https://optimistic.etherscan.io/tx/0x816f9e289d8b9dee9a94086c200c0470c6456603c967f82ab559a5931fd181c2

Análise do processo de ataque

A equipe do projeto Sonne Finance aprovou recentemente uma proposta para adicionar o mercado de VELO à Sonne Finance (https://twitter.com/SonneFinance/status/1786871066075206044), e organizou cinco transações através da carteira multiassinatura para serem executadas dois dias depois ( https://optimistic.etherscan.io/tx/0x18ebeb958b50579ce76528ed812025949dfcff8c2673eb0c8bc78b12ba6377b7), essas cinco transações são usadas para criar o mercado de VELO (contrato soVELO) e definir algumas configurações-chave do mercado, como definir o modelo de taxa de juros, definir o oráculo de preço e definir os fatores de hipoteca, etc. Depois que o mercado de VELO é criado, os usuários podem depósito VELO tokens para cunhar tokens soVELO, que por sua vez podem ser usados para emprestar outros soTokens.

preparação

ataques A etapa de preparação do ataque é principalmente para o atacante criar um mercado de VELO (contrato soVELO) com base nas informações da proposta do projeto Sonne Finance após o período de bloqueio de dois dias da proposta ter expirado, configurar configurações de chave e cunhar VELO tokens no contrato soVELO hipotecando-os. tokens soVELO, e também envia os tokens VELO que detém diretamente para o contrato soVELO para aumentar a taxa de câmbio e preparar para lucrar com ataques subsequentes.

As etapas específicas são as seguintes:

1. Após o término do período de bloqueio de dois dias, o invasor primeiro empacota as operações das quatro primeiras transações organizadas na proposta em uma transação (transação 0x45c0cc), que é usada para criar o mercado de VELO (contrato soVELO) e definir a configuração da chave. Quando VELO mercado é inicializado, exchangeRate é definido como "200,000,000,000,000,000,000,000".

2. O invasor chama a função "cunhar" do contrato soVELO para depósito VELO tokens e cunhar tokens soVELO. O invasor especifica "mintAmount" como "400.000.001" (o número de tokens VELO). Como pode ser visto a partir da função "exchangeRateStoredInternal", uma vez que o "_totalSuppl" do token soVELO é 0 neste momento, exchangeRate é o valor definido na etapa 1. De acordo com a fórmula " mintTokens = actualMintAmount / exchangeRate ", o número calculado de tokens soVELO que devem ser cunhados neste momento é 2. Em curto, nesta etapa, o invasor deposita tokens VELO com um valor de "400.000.001" no contrato soVELO, e o invasor obtém tokens soVELO com um valor de 2.

soVELO.cunhar:

1. O invasor enviou tokens VELO com um valor de "2.552.964.259.704.265.837.526" para o contrato soVELO enviando diretamente VELO tokens para o contrato soVELO. Neste momento, o número de tokens de VELO detidos pelo contrato soVELO aumentou, mas como não havia novos tokens soVELO O moeda é cunhado, então totalSupply permanece inalterado, o que significa que a taxa de câmbio calculada de acordo com a fórmula de cálculo exchangeRate se tornará maior neste momento.

2. O atacante transferiu os tokens soVELO mantidos várias vezes e, finalmente, transferiu-os para outro ataque EOA 0xae4a.

Ataque com fins lucrativos

A fase de lucro do ataque envolve principalmente o atacante executando a quinta transação da proposta e emprestando tokens VELO diretamente ao contrato soVELO através de empréstimos flash para aumentar ainda mais a taxa de câmbio. Em seguida, o invasor usa o token soVELO com um valor de 2 em sua mão para emprestar tokens subjacentes, como WETH e USDC, de outros contratos soToken (como soWETH, soUSDC, etc.), e essas partes se tornam o lucro do invasor. Em seguida, o atacante foi resgatar seu token subjacente no contrato soVELO. Devido ao aumento da taxa de câmbio e à perda de precisão no cálculo dos tokens soVELO que precisam ser destruídos para resgate, o atacante acabou usando apenas o token soVELO com um valor de 1. Quase todos os tokens de VELO depositados anteriormente foram resgatados, o que pode ser entendido como o invasor usando os tokens soVELO extras com um valor de 1 para ganhar tokens subjacentes, como WETH e USDC, tomando emprestado de outros soTokens. O atacante usou a mesma técnica para repetir o ataque muitas vezes e, finalmente, obteve enormes lucros.

As etapas específicas são as seguintes:

1. O atacante executa a quinta transação na proposta e define o fator de empréstimo especificado na proposta.

2. O atacante empresta tokens VELO tokens com um valor de "35.469.150.965.253.049.864.450.449" do pool VolatileV2 AMM - USDC/VELO, que aciona a função de gancho do atacante. Na função de gancho, o atacante continua a executar a operação de ataque.

3. O atacante envia os tokens de VELO que possui para o contrato soVELO para aumentar ainda mais a taxa de câmbio. Atualmente, há um total de VELO tokens com um valor de "35.471.703.929.512.754.530.287.976" no contrato soVELO (a soma de VELO tokens transferidos três vezes pelo atacante).

4. O atacante cria um novo contrato 0xa16388a6210545b27f669d5189648c1722300b8b. No construtor, ele transfere os 2 tokens soVELO que detém para o contrato recém-criado 0xa163 (doravante referido como o atacante 0xa163).

5. O atacante 0xa163 usou os tokens soVELO que detinha para pedir emprestado WETH com um valor de "265.842.857.910.985.546.929" da soWETH.

6. O invasor 0xa163 chama a função "redeemUnderlying" do soVELO, especificando o valor dos tokens de VELO resgatados como "35.471.603.929.512.754.530.287.976" (quase o número de tokens de VELO que o invasor transferiu ou hipotecou anteriormente no contrato soVELO). Neste momento, é necessário A fórmula "redeemTokens = redeemAmountIn / exchangeRate" é usada para calcular o número de tokens soVELO que precisam ser destruídos para resgate.

Como pode ser visto a partir da função "exchangeRateStoredInternal", uma vez que _totalSupply é 2 em vez de 0, o valor de exchangeRate precisa ser calculado. De acordo com a fórmula "exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply", a taxa de câmbio atual é "17,735,851,964,756,377,265,143,988,000,0 00,000,000,000,000 ", este valor é muito maior do que o conjunto inicial de taxa de câmbio "200,000,000,000,000,000,000,000,000,00".

O valor de " redeemTokens " calculado com base na nova taxa de câmbio é " 1,99 ". Devido às características de arredondamento para baixo de Solidity, o valor de " redeemTokens " acaba sendo 1. Isso significa que o invasor 0xa163 usado tokens soVELO com um valor de 1 para resgatar quase todos os tokens VELO depositados anteriormente. Ao mesmo tempo, o atacante também 0xa163 ganhou WETH com um valor de "265.842.857.910.985.546.929" emprestado da soWETH.

soVELO.redeemSubjacente:

soVELO.exchangeRateStoredInternal:

1. O atacante 0xa163 transferiu todos os WETH emprestados e resgatou VELO tokens para o atacante de nível superior e, em seguida, se autodestruiu.

2. O atacante chama a função "liquidateBorrow" do soWETH para liquidar alguns dos ativos emprestados do contrato recém-criado 0xa163 a ordem recuperar o token soVELO bloqueado com um valor de 1. Atualmente, o atacante só detém tokens soVELO com um valor de 1.

3. O atacante chama a função "cunhar" de soVELO e mais uma vez hipoteca e cunha tokens soVELO com o objetivo de reunir tokens soVELO suficientes com um valor de 2 e, em seguida, executa as etapas 3-8 acima novamente para lucrar com outros tokens inúteis.

4. O atacante executa a operação na etapa 9 várias vezes, paga o empréstimo flash e deixa o mercado com lucro.

Como $100 alavanca $6,5 milhões

Após o ataque, o usuário @tonyke_bot no X cunhou 0,00000011 soVELO ao apostar 1144 tokens VELO no contrato soVELO na transação 0x0a284cd. A razão pela qual esta operação pode impedir o atacante de novos ataques é porque esta transação altera o tamanho do totalSupply no soVELO e o número de tokens de VELO totalCash detidos, e o impacto do crescimento do totalSupply no cálculo do exchangeRate é maior do que o impacto do crescimento do totalCash. Portanto, o exchangeRate torna-se menor, fazendo com que o atacante não mais longo ser capaz de usar a perda de precisão para ganhar soVELO ao conduzir um ataque, tornando o ataque sem mais longo possível.

Rastreamento de dinheiro

O atacante transferiu os fundos pouco depois de pegar os lucros ilegais. A maior parte dos fundos foi transferida para os quatro endereços seguintes. Alguns mudaram de endereço para continuar o ataque, e outros foram por lavagem de dinheiro:

1、0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

O invasor transferiu 198 WETH para esse endereço e, em seguida, o endereço usou o mesmo método de ataque para obter ganhos ilegais nas seguintes transações:

Após o ataque, o endereço transferiu os ganhos ilegais acima mencionados para 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb.

2、0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

O atacante transferiu 724277 USDC e 2353 VELO para este endereço e trocou USDC por Éter. Em seguida, alguns fundos foram imediatamente transferidos para o Stargate cadeia cruzada ponte. A maioria dos fundos ilícitos permanece neste endereço:

3、0xbd18100a168321701955e348f03d0df4f517c13b

O agressor transferiu 33 WETH para este endereço e usou corrente de peeling para tentar lavar dinheiro. A ligação relativa ao branqueamento de capitais é a seguinte:

0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003 093c2b4 -> 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795。

4、0x4fac0651bcc837bf889f6a7d79c1908419fe1770

O atacante transferiu 563 WETH para este endereço e, posteriormente, para 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68, sem mais nenhuma ação até agora.

O método de lavagem de dinheiro do atacante desta vez é relativamente profissional, e os métodos mostram uma tendência de diversidade. Portanto, para nós participantes da Web3, devemos continuar a melhorar nossas capacidades de combate à lavagem de dinheiro em termos de segurança e melhorar a segurança dos projetos Defi por meio de KYT, AML e outros produtos de segurança de transações blockchain relacionados.

Conselhos de segurança

1、Mantenha-se atualizado com auditorias e testes de contratos. Realize uma auditoria abrangente antes da implantação do contrato inteligente, prestando especial atenção a todas as partes que envolvem cálculos financeiros. Primeiro, use testes automatizados e aproveite as atualizações em tempo real das bibliotecas de vulnerabilidades para conduzir verificações de segurança de contrato eficientes (o setor também abriu gradualmente algumas ferramentas de auditoria de segurança maduras, incluindo o ZAN AI SCAN), enquanto combina auditoria manual para solucionar problemas que exigem conhecimento aprofundado do setor.

2、A perda de precisão precisa ser levada a sério. Os problemas de segurança causados pela perda de precisão são infinitos, especialmente em projetos Defi, onde a perda de precisão muitas vezes leva a sérias perdas financeiras. Recomenda-se que as partes do projeto e os auditores de segurança analisem cuidadosamente os códigos com perda de precisão no projeto e realizem testes para evitar ao máximo essa vulnerabilidade.

1. Recomenda-se que a criação de um mercado semelhante ao cToken em Compound e a primeira operação de fundição de hipotecas sejam realizadas por usuários privilegiados para evitar serem manipulados por invasores e, assim, manipular a taxa de exchange.

2. Quando há variáveis-chave no contrato que dependem do valor de " this.balance " ou " token.balanceOf() ", você precisa considerar cuidadosamente as condições para a mudança da variável chave, como se é permitido transferir diretamente moeda nativa ou tokens para o contrato. para alterar o valor da variável, ou o valor da variável só pode ser alterado chamando uma função específica.

Declaração de exoneração de responsabilidade:

1. Este artigo foi reproduzido a partir de [ZAN]. Todos os direitos autorais pertencem ao autor original [ZAN]. Se houver objeções a essa reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso imediatamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.