Em 15 de maio de 2024, a Sonne Finance sofreu um ataque à Optimism na cadeia, com perdas de até US$ 2 k 0000.

Após o ataque, o usuário @tonyke_bot no X twittou que protegeu cerca de 100 dólares em tokens do pool de garantia da Sonne Finance (também conhecido como mercado, semelhante ao cToken no Compound), que restavam cerca de 6,5 milhões de dólares.

（\_bot/status/1790547461611860182）

Depois de descobrir o ataque, a equipe do projeto Sonne Finance rapidamente suspendeu todos os mercados no Optimism e disse que os mercados na Base estavam seguros.

（**）

Briefing de Ataque

Sonne Finance é um fork do protocolo de empréstimo e empréstimo descentralizado Compound V2 no Optimism, que oferece serviços financeiros para indivíduos, instituições e protocolos. O protocolo Sonne Finance agrega os ativos de token dos usuários para formar um pool de liquidez de empréstimo, oferecendo aos usuários um serviço de empréstimo semelhante a um banco. Assim como no Compound, os participantes do protocolo podem depositar seus tokens no pool de liquidez de empréstimo do Sonne Finance e receber o token soToken (semelhante ao cToken) como comprovante. O soToken é um ativo com juros que gera receita à medida que os blocos são processados e também recebe incentivos com o token SONNE. Com o soToken em mãos, os participantes também podem emprestar outros tokens do pool de ativos de empréstimo da Sonne, por exemplo, podem depositar uma quantidade específica de USDC para obter o comprovante soUSDC e emprestar WETH para maior circulação. O empréstimo e empréstimo com garantia do protocolo Sonne Finance pode ter uma relação de ativos de muitos para muitos. Durante o processo de empréstimo e empréstimo com garantia, o protocolo calculará automaticamente o fator de saúde (Health Factor) do endereço do participante. Quando o fator de saúde for inferior a 1, os ativos de garantia do endereço serão liquidados e o liquidante também receberá uma recompensa de liquidação.

A relação entre o token subjacente depositado pelo usuário e o número de cunhagem soTokens está relacionada principalmente a uma variável chamada exchangeRate, que pode ser usada aproximadamente para representar o valor de cada token soToken mais longo ou menos subjacente. A taxa de câmbio é calculada da seguinte forma:

Na fórmula acima, totalCash refere-se ao número de tokens subjacentes detidos por soToken, totalBorrows refere-se à quantidade de tokens subjacentes emprestados em um mercado, totalReserves refere-se à quantidade total de reservas (incluindo juros pagos pelos mutuários) e totalSupply refere-se ao número de cunhagem soTokens.

Ao resgatar, o usuário pode especificar a quantidade de tokens subjacentes a serem resgatados, resgatarAmount, para calcular o número de soTokens que precisam ser queimados, resgatarTokens, o método de cálculo é aproximadamente "redeemTokens = redeemAmount / exchangeRat", note que não há processamento de perda de precisão aqui.

Este incidente de ataque é essencialmente devido a uma operação de cunhagem inicial na criação do mercado (soToken), em que o atacante cunhou uma pequena quantidade de token subjacente para produzir uma quantidade muito pequena de soToken. Isso resultou em um valor muito baixo para o campo "totalSupply" do soToken. Em seguida, o atacante explorou a vulnerabilidade de perda de precisão nos contratos Solidity e enviou diretamente o token subjacente para o contrato do soToken (sem cunhagem de soToken). Isso significa que o campo "totalSupply" permanece inalterado, enquanto o campo "totalCash" aumenta. Essa operação faz com que a variável "totalCash" no contrato aumente, mas o "totalSupply" permanece o mesmo, resultando em um aumento na taxa de câmbio. No final, quando o atacante resgata o token subjacente, ele precisa queimar menos soToken do que os cunhados durante a operação de cunhagem. O atacante usa os soToken ganhos para emprestar os tokens subjacentes WETH e USDC de outros soTokens (como soWETH e soUSDC), obtendo lucros de até 20 milhões de dólares.

**Endereço críticos envolvidos no ataque

Negociação Pronta para Ataque:

\u003e > ** \u003e \u003e

Atacando negociações lucrativas:

\u003e > > **

\u003e

Ataque EOA relacionados Endereço:

\u003e \u003e

0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb \u003e >

\u003e \u003e

0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43 \u003e

Endereço relacionado ao atacante (contrato):

\u003e

0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8

\u003e

0x02fa2625825917e9b1f8346a465de1bbc150c5b9 > \u003e

token subjacente(VELO Token V2):

>

0x9560e827af36c94d2ac33a39bce1fe78631088db \u003e \u003e

漏洞合约（soVELO, semelhante ao cToken do Compound）：

\u003e \u003e

0xe3b81318b1b6776f0877c3770afddff97b9f5fe5 > Translated text in Portuguese (Portugal): >

X 上 @tonyke_bot 用户救援交易：

\u003e \u003e **

\u003e

Análise do processo de ataque

Sumário do Contexto

(Translated text in Portuguese (Portugal))

Sonne Finance recentemente aprovou uma proposta para adicionar o mercado VELO à Sonne Finance (), e organizou cinco transações para serem executadas em dois dias usando uma carteira com várias assinaturas (). Essas cinco transações são usadas para criar o mercado VELO (contrato soVELO) e configurar algumas configurações-chave desse mercado, como modelo de taxa de juros, máquina Oracle de preços e fator de garantia. Após a criação do mercado VELO, os usuários podem depositar tokens VELO para cunhar tokens soVELO, que podem ser usados para empréstimos de outros tokens soToken.

Preparação para Ataques

O estágio de preparação do ataque envolve principalmente o atacante criando um mercado VELO (contrato soVELO) com base nas informações fornecidas pela equipe do projeto Sonne Finance na proposta, configurando as configurações-chave e cunhando tokens soVELO através do bloqueio de tokens VELO no contrato soVELO. Ao mesmo tempo, o atacante também aumentará a taxa de câmbio enviando diretamente os tokens VELO que possui para o contrato soVELO, preparando-se para obter lucro com o ataque posteriormente.

Passo a passo específico:

1. Após o término do período de bloqueio de dois dias, o atacante primeiro agrupa as operações das quatro primeiras transações especificadas na proposta em uma única transação (transação 0x45c0cc) para criar o mercado VELO (contrato soVELO) e configurar as principais configurações. Ao iniciar o mercado VELO, a taxa de câmbio é definida como "200.000.000.000.000.000.000.000.000".
2. O atacante chama a função "mint" do contrato soVELO para depositar tokens VELO e cunhar tokens soVELO. O atacante especifica "mintAmount" como "400.000.001" (a quantidade de tokens VELO). A partir da função "exchangeRateStoredInternal", podemos ver que, neste momento, o "totalSuppl" dos tokens soVELO é 0, portanto, a taxa de câmbio é o valor definido no passo 1. De acordo com a fórmula "mintTokens = actualMintAmount / exchangeRate", o número de tokens soVELO a serem cunhados é calculado como 2. Em resumo, neste passo, o atacante deposita 400.000.001 tokens VELO no contrato soVELO e recebe 2 tokens soVELO.

soVELO.mint:

3. O atacante enviou tokens VELO diretamente para o contrato soVELO, enviando um valor de "2.552.964.259.704.265.837.526" tokens VELO. Neste momento, o contrato soVELO possui mais tokens VELO, mas como não há nenhuma nova cunhagem de tokens soVELO, o totalSupply permanece inalterado, o que significa que a taxa de câmbio calculada de acordo com a fórmula exchangeRate aumentará. 4. O atacante transfere várias vezes os tokens soVELO que possui, e no final os transfere para outro EOA de ataque, 0xae4a.

Ataque ao lucro

O estágio de lucro do ataque é principalmente quando o invasor executa a quinta transação da proposta e empresta diretamente tokens VELO para o contrato soVELO por meio de empréstimos flash, a fim de aumentar ainda mais a taxa de câmbio. Em seguida, o invasor usa os tokens soVELO com valor de 2 para emprestar tokens subjacentes, como WETH, USDC, etc., de outros contratos de tokens soToken. Essas partes se tornam os lucros do invasor. Em seguida, o invasor resgata seus tokens subjacentes do contrato soVELO. Devido ao aumento da taxa de câmbio e às perdas de precisão ao calcular os tokens soVELO a serem destruídos durante o resgate, o invasor consegue resgatar quase todos os tokens VELO depositados usando apenas um token soVELO com valor de 1. Isso significa que o invasor usa tokens soVELO com valor de 1 para ganhar tokens subjacentes, como WETH, USDC, etc., por meio de empréstimos de outros soTokens. O invasor repete esse método várias vezes para obter grandes lucros.

Os passos específicos são os seguintes:

1. O atacante executa a quinta transação no caso, definindo o fator de empréstimo especificado na proposta.
2. O atacante retira instantaneamente do pool VolatileV2 AMM - USDC/VELO um valor de VELO tokens igual a "35,469,150,965,253,049,864,450,449", o que aciona a função hook do atacante. Na função hook, o atacante continua executando a operação de ataque.
3. O atacante envia os tokens VELO que possui para o contrato soVELO, a fim de aumentar ainda mais a taxa de câmbio. Atualmente, o contrato soVELO possui um total de tokens VELO no valor de "35.471.703.929.512.754.530.287.976" (incluindo os tokens VELO transferidos pelo atacante três vezes).
4. O atacante cria um novo contrato 0xa16388a6210545b27f669d5189648c1722300b8b, onde transfere 2 tokens soVELO detidos para o novo contrato criado 0xa163 (doravante referido como atacante 0xa163).
5. O atacante 0xa163 empresta um WETH com o valor de "265.842.857.910.985.546.929" do Token soWETH que detém.
6. O atacante 0xa163 chama a função "redeemUnderlying" de soVELO, especificando o valor de resgate do token VELO como "35.471.603.929.512.754.530.287.976" (quase a quantidade de tokens VELO que o atacante havia transferido ou colateralizado anteriormente no contrato soVELO). Neste momento, é necessário calcular a quantidade de tokens soVELO que devem ser destruídos com base na fórmula "redeemTokens = redeemAmountIn / exchangeRate".

A partir da função "exchangeRateStoredInternal", pode-se ver que, como neste momento \_totalSupply é 2 em vez de 0, é necessário calcular o valor de exchangeRate usando a fórmula "exchangeRate = (totalCash + totalBorrows - totalReserves) / totalSupply". Atualmente, o valor de exchangeRate é "17,735,851,964,756,377,265,143,988,000,000,000,000,000,000", o qual é muito maior do que o exchangeRate inicial definido de "200,000,000,000,000,000,000,000,00".

De acordo com a nova taxa de câmbio, o valor calculado para "redeemTokens" é "1.99". Devido à característica de arredondamento para baixo do Solidity, o valor de "redeemTokens" acaba sendo 1. Isso significa que o atacante 0xa163 resgatou praticamente todos os tokens VELO previamente depositados usando 1 token soVELO. Ao mesmo tempo, o atacante 0xa163 também lucrou com o empréstimo de um valor de WETH igual a "265,842,857,910,985,546,929" do soWETH.

soVELO.redeemSubjacente:

soVELO.exchangeRateStoredInternal: 7. O atacante 0xa163 transfere todo o WETH emprestado e resgatado VELO Token para o atacante superior, e então se autodestrói. 8. O atacante chama a função "liquidateBorrow" do "soWETH" para liquidar os ativos do contrato 0xa163 criado anteriormente, com o objetivo de recuperar o token soVELO com valor de bloqueio 1. Atualmente, o atacante possui apenas o token soVELO com valor 1. 9. O atacante chama a função "mint" do soVELO para mais uma vez fazer cunhagem do token soVELO, com o objetivo de obter um total de 2 tokens soVELO e, em seguida, executar novamente as etapas 3 a 8 acima mencionadas para lucrar com outros tokens subjacentes. 10. O atacante executa o passo 9 várias vezes, paga os empréstimos flash e sai do mercado com lucro.

Como alavancar $100 para $650 milhões

Depois do ataque, o usuário @tonyke_bot na transação 0x0a284cd, na Gate.io, fez o depósito de 1144 tokens VELO no contrato soVELO, e cunhou 0.00000011 soVELO. A razão pela qual essa operação impede que o atacante continue atacando é porque essa transação altera o tamanho do totalSupply em soVELO e a quantidade de tokens VELO em totalCash. O crescimento do totalSupply tem um impacto maior no cálculo da taxa de câmbio (exchangeRate) do que o crescimento do totalCash. Portanto, a taxa de câmbio diminui, o que impede que o atacante ganhe soVELO explorando a perda de precisão. Isso faz com que o ataque não possa mais prosseguir.

Rastreamento de Fundos

Os atacantes transferiram os fundos pouco depois de se apoderarem dos lucros ilegais, a maioria dos quais foram transferidos para os seguintes 4 endereços, alguns para continuar o ataque noutra Endereço e outros para Lavagem de dinheiro:

1. 0x4ab93fc50b82d4dc457db85888dfdae28d29b98d

O atacante transferiu 198 WETH para o Endereço e, em seguida, o Endereço usou as mesmas táticas de ataque para obter lucros ilegais nas seguintes transações:

Após o ataque, o Endereço transferiu os lucros para 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb.

2. 0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb

O atacante transferiu 724277 USDC e 2353 VELO para este endereço e converteu os USDC em Ether. Em seguida, imediatamente transferiu parte dos fundos para a ponte de cadeia cruzada Stargate, enquanto o restante dos fundos ilegais permanece neste endereço:

3. 0xbd18100a168321701955e348f03d0df4f517c13b

O atacante transferiu 33 WETH para o Endereço e usou a corrente de peeling para tentar Lavagem de dinheiro, o link Lavagem de dinheiro é o seguinte:

0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003093c2b4 -> * 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795*。

4. 0x4fac0651bcc837bf889f6a7d79c1908419fe1770

O atacante transferiu 563 WETH para esse endereço e em seguida transferiu para 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68, e não há mais atividades por enquanto.

O método de lavagem de dinheiro usado pelos atacantes desta vez é relativamente profissional e apresenta uma tendência de diversidade nas táticas. Portanto, como participantes do Web3, é necessário melhorar continuamente nossa capacidade de combater a lavagem de dinheiro, aprimorando a segurança de projetos DeFi por meio de produtos de segurança de transações em blockchain, como KYT e AML.

Sugestões de segurança

1. Perda de precisão precisa ser prestada atenção. Problemas de segurança causados pela perda de precisão surgem um após o outro, especialmente em projetos Defi, onde a perda de precisão muitas vezes leva a sérias perdas financeiras. Recomenda-se que a equipe do projeto e os auditores de segurança analisem cuidadosamente o código com perda de precisão no projeto e façam um bom trabalho testando-o para evitar a vulnerabilidade tanto quanto possível.
2. Recomenda-se que a criação e as primeiras operações de staking cunhagem de um mercado semelhante ao cToken in Compound sejam realizadas por usuários privilegiados para evitar serem manipulados por atacantes, de modo a manipular o Taxa de câmbio.
3. Ao considerar se uma variável-chave no contrato depende do valor de "this.balance" ou "token.balanceOf()", é importante considerar cuidadosamente as condições nas quais essa variável-chave pode ser alterada. Por exemplo, se é permitido alterar o valor dessa variável diretamente através da transferência de moeda nativa ou tokens para o contrato, ou se essa variável só pode ser alterada através da chamada de uma função específica.

Este artigo foi escrito em colaboração por Cara (conta X @Cara6289) e XiG (conta X @SHXiGi) da equipe ZAN.