Análise do ataque à Sonne Finance
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 eles protegeram 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 pausou todos os mercados no Optimism e afirmou que os mercados na Base estavam seguros.
(https://twitter.com/SonneFinance/status/1790535383005966554)
Breve descrição do ataque
A Sonne Finance é uma protocolo de empréstimos descentralizada que bifurca o Compound V2 no Optimism, 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 uma pool de liquidez de empréstimos, fornecendo aos usuários um negócio de empréstimos semelhante a 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). O 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 emprestar outros tokens do pool de ativos de empréstimo 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 circulação posterior. O crédito hipotecário no protocolo Sonne Finance pode ser uma relação de muitos para muitos ativos. Durante o processo de concessão de crédito imobiliário, o protocolo calculará automaticamente o fator de saúde (Fator Saúde) do endereço do participante. Quando o fator saúde é menor que 1, a hipoteca do endereço será apoiar 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á principalmente relacionada a uma variável chamada exchangeRate. Essa variável pode ser usada aproximadamente para indicar quanto vale cada token subjacente cada soToken. A fórmula de cálculo para a taxa de câmbio é 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 cunhado.
Ao resgatar, os usuários podem especificar o número de tokens subjacentes que desejam resgatar, redeemAmount, para calcular o número de soTokens que precisam ser destruídos, redeemTokens. 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 desse ataque é que, quando o mercado (soToken) foi criado, o invasor executou a primeira operação de lançamento de hipoteca e cunhou muito poucos soTokens com uma pequena quantidade de tokens subjacentes, resultando no valor "totalSupply" do 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 do método staking + casting 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 para outros soTokens (como soWETH, soUSDC) e, finalmente, obtém Lucros que chegaram a US$ 20 milhões.
Principais endereços envolvidos no ataque
Transações de preparação de ataque:
Ataque transações lucrativas:
Endereços relacionados ao EOA de ataque:
0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb
0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43
Endereço relacionado ao invasor (contrato):
0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8
0x02fa2625825917e9b1f8346a465de1bbc150c5b9
token(VELO Token V2 subjacente):
0x9560e827af36c94d2ac33a39bce1fe78631088db
Contrato de vulnerabilidade (soVELO, semelhante ao cToken da Compound):
0xe3b81318b1b6776f0877c3770afddff97b9f5fe5
@tonyke_bot Transação de resgate do usuário no X:
Análise do processo de ataque
Recapitulação
A equipe de projeto da 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 por meio da carteira multiassinatura a serem executadas dois dias depois ( https://optimistic.etherscan.io/tx/0x18ebeb958b50579ce76528ed812025949dfcff8c2673eb0c8bc78b12ba6377b7), essas cinco transações são usadas para criar o mercado VELO (contrato soVELO) e definir algumas configurações importantes do mercado, como definir o modelo de taxa de juros, definir o oráculo de preços, definir os fatores de hipoteca, etc. Depois que o mercado de VELO é criado, os usuários podem depósito VELO tokens para como tokens soVELO, que por sua vez podem ser usados para emprestar outros soTokens.
preparação
paraataque O estágio de preparação do ataque é principalmente para o atacante criar um mercado VELO (contrato soVELO) com base nas informações na 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 como VELO tokens no contrato soVELO hipotecando-os. soVELO tokens, 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:
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, a taxa de câmbio é definida como "200.000.000.000.000.000.000.000.000".
O invasor chama a função "como" do contrato soVELO para depósito VELO tokens e como tokens soVELO. O invasor especifica "mintAmount" como "400.000.001" (o número de tokens VELO). Como pode ser visto na função "exchangeRateStoredInternal", já 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.como:
O atacante enviou tokens VELO com um valor de "2.552.964.259.704.265.837.526" para o contrato soVELO enviando diretamente tokens VELO para o contrato soVELO. Neste momento, o número de tokens VELO mantidos 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 da taxa de câmbio se tornará maior neste momento.
O invasor transferiu os tokens soVELO mantidos várias vezes e, finalmente, transferiu-os para outro ataque EOA 0xae4a.
Ataque com lucro
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 por meio 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 invasor acabou usando apenas o token soVELO com um valor de 1. Quase todos os tokens 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 acabou obtendo grandes lucros.
As etapas específicas são as seguintes:
O invasor executa a quinta transação na proposta e define o fator de empréstimo especificado na proposta.
O atacante empresta 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 invasor. Na função de gancho, o atacante continua a executar a operação de ataque.
O atacante envia os tokens 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 em três vezes pelo atacante).
O atacante cria um novo contrato 0xa16388a6210545b27f669d5189648c1722300b8b. No construtor, ele transfere os 2 tokens soVELO que possui para o 0xa163 de contrato recém-criado (doravante referido como o atacante 0xa163).
O atacante 0xa163 usou os tokens soVELO que detinha para emprestar WETH com um valor de "265.842.857.910.985.546.929" da soWETH.
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 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 na função "exchangeRateStoredInternal", como _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 a taxa de câmbio inicial definida "200.000.000.000.000.000.000.000".
O valor de " redeemTokens " calculado com base na nova taxa de câmbio é " 1.99 ". Devido às características de arredondamento para baixo do 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 ganhou 0xa163 WETH com um valor de "265.842.857.910.985.546.929" emprestado da soWETH.
soVELO.redeemSubjacente:
soVELO.exchangeRateStoredInternal:
O atacante 0xa163 transferiu todos os WETH emprestados e resgatou VELO tokens para o invasor de nível superior e, em seguida, se autodestruiu.
O invasor chama a função "liquidateBorrow" de soWETH para liquidar alguns dos ativos emprestados do contrato recém-criado 0xa163 em ordem para recuperar o token soVELO bloqueado com um valor de 1. Atualmente, o atacante só possui tokens soVELO com um valor de 1.
O invasor chama a função "como" de soVELO e mais uma vez hipoteca e cunha tokens soVELO com o objetivo de coletar 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.
O atacante realiza a operação na etapa 9 várias vezes, paga o empréstimo relâmpago e sai do mercado com lucro.
Como US$ 100 alavancam US$ 6,5 milhões
Após o ataque, o usuário @tonyke_bot no X cunhou 0,00000011 soVELO apostando 1144 tokens VELO no contrato soVELO na transação 0x0a284cd. A razão pela qual esta operação pode impedir o invasor de novos ataques é porque esta transação altera o tamanho de totalSupply em soVELO e o número de tokens de VELO totalCash detidos, e o impacto do crescimento de totalSupply no cálculo de exchangeRate é maior do que o impacto do crescimento de totalCash. Portanto, a taxa de câmbio torna-se menor, fazendo com que o atacante não mais tempo ser capaz de usar a perda de precisão para ganhar soVELO ao realizar um ataque, fazendo com que o ataque não mais tempo possível.
Rastreamento de dinheiro
O atacante transferiu os fundos logo após pegar os recursos ilegais. A maior parte dos recursos foi transferida para os quatro endereços seguintes. Alguns foram para mudar de endereço para continuar o ataque, e outros foram para 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 Ether. Em seguida, alguns fundos foram imediatamente transferidos para o Stargate cadeia cruzada ponte. A maior parte dos fundos ilícitos permanece neste endereço:
3、0xbd18100a168321701955e348f03d0df4f517c13b
O agressor transferiu 33 WETH para esse endereço e usou corrente de descasca para tentar lavar dinheiro. O vínculo de lavagem de dinheiro é o seguinte:
0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003 093c2b4 -> 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795。
4、0x4fac0651bcc837bf889f6a7d79c1908419fe1770
O atacante transferiu 563 WETH para este endereço e, posteriormente, para 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68, sem nenhuma outra ação até o momento.
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 a auditoria e os 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 (a indústria também abriu gradualmente algumas ferramentas de auditoria de segurança maduras, incluindo 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 revisem cuidadosamente os códigos com perda de precisão no projeto e realizem testes para evitar ao máximo essa vulnerabilidade.
Recomenda-se que a criação de um mercado semelhante ao cToken no Compound e a primeira operação de lançamento de hipoteca sejam realizadas por usuários privilegiados para evitar serem manipulados por invasores e, assim, manipular a taxa exchange.
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.
Isenção de responsabilidade:
- Este artigo foi reproduzido 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 prontamente.
- 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.
- 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.
Artigos relacionados
Introdução à Blockchain de Privacidade Aleo
Lançamento da Babilônia: Repensando o Ecossistema BTCFi
Uma Análise Comparativa dos Requisitos de Custódia de Ativos Cripto e Conformidade nos EUA, Hong Kong e Singapura: Insights das Acusações da SEC Contra Galois Capital
Análise do ataque à Sonne Finance
Breve descrição do ataque
Principais endereços envolvidos no ataque
Análise do processo de ataque
Como US$ 100 alavancam US$ 6,5 milhões
Rastreamento de dinheiro
Conselhos de segurança
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 eles protegeram 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 pausou todos os mercados no Optimism e afirmou que os mercados na Base estavam seguros.
(https://twitter.com/SonneFinance/status/1790535383005966554)
Breve descrição do ataque
A Sonne Finance é uma protocolo de empréstimos descentralizada que bifurca o Compound V2 no Optimism, 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 uma pool de liquidez de empréstimos, fornecendo aos usuários um negócio de empréstimos semelhante a 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). O 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 emprestar outros tokens do pool de ativos de empréstimo 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 circulação posterior. O crédito hipotecário no protocolo Sonne Finance pode ser uma relação de muitos para muitos ativos. Durante o processo de concessão de crédito imobiliário, o protocolo calculará automaticamente o fator de saúde (Fator Saúde) do endereço do participante. Quando o fator saúde é menor que 1, a hipoteca do endereço será apoiar 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á principalmente relacionada a uma variável chamada exchangeRate. Essa variável pode ser usada aproximadamente para indicar quanto vale cada token subjacente cada soToken. A fórmula de cálculo para a taxa de câmbio é 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 cunhado.
Ao resgatar, os usuários podem especificar o número de tokens subjacentes que desejam resgatar, redeemAmount, para calcular o número de soTokens que precisam ser destruídos, redeemTokens. 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 desse ataque é que, quando o mercado (soToken) foi criado, o invasor executou a primeira operação de lançamento de hipoteca e cunhou muito poucos soTokens com uma pequena quantidade de tokens subjacentes, resultando no valor "totalSupply" do 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 do método staking + casting 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 para outros soTokens (como soWETH, soUSDC) e, finalmente, obtém Lucros que chegaram a US$ 20 milhões.
Principais endereços envolvidos no ataque
Transações de preparação de ataque:
Ataque transações lucrativas:
Endereços relacionados ao EOA de ataque:
0x5d0d99e9886581ff8fcb01f35804317f5ed80bbb
0xae4a7cde7c99fb98b0d5fa414aa40f0300531f43
Endereço relacionado ao invasor (contrato):
0xa78aefd483ce3919c0ad55c8a2e5c97cbac1caf8
0x02fa2625825917e9b1f8346a465de1bbc150c5b9
token(VELO Token V2 subjacente):
0x9560e827af36c94d2ac33a39bce1fe78631088db
Contrato de vulnerabilidade (soVELO, semelhante ao cToken da Compound):
0xe3b81318b1b6776f0877c3770afddff97b9f5fe5
@tonyke_bot Transação de resgate do usuário no X:
Análise do processo de ataque
Recapitulação
A equipe de projeto da 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 por meio da carteira multiassinatura a serem executadas dois dias depois ( https://optimistic.etherscan.io/tx/0x18ebeb958b50579ce76528ed812025949dfcff8c2673eb0c8bc78b12ba6377b7), essas cinco transações são usadas para criar o mercado VELO (contrato soVELO) e definir algumas configurações importantes do mercado, como definir o modelo de taxa de juros, definir o oráculo de preços, definir os fatores de hipoteca, etc. Depois que o mercado de VELO é criado, os usuários podem depósito VELO tokens para como tokens soVELO, que por sua vez podem ser usados para emprestar outros soTokens.
preparação
paraataque O estágio de preparação do ataque é principalmente para o atacante criar um mercado VELO (contrato soVELO) com base nas informações na 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 como VELO tokens no contrato soVELO hipotecando-os. soVELO tokens, 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:
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, a taxa de câmbio é definida como "200.000.000.000.000.000.000.000.000".
O invasor chama a função "como" do contrato soVELO para depósito VELO tokens e como tokens soVELO. O invasor especifica "mintAmount" como "400.000.001" (o número de tokens VELO). Como pode ser visto na função "exchangeRateStoredInternal", já 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.como:
O atacante enviou tokens VELO com um valor de "2.552.964.259.704.265.837.526" para o contrato soVELO enviando diretamente tokens VELO para o contrato soVELO. Neste momento, o número de tokens VELO mantidos 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 da taxa de câmbio se tornará maior neste momento.
O invasor transferiu os tokens soVELO mantidos várias vezes e, finalmente, transferiu-os para outro ataque EOA 0xae4a.
Ataque com lucro
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 por meio 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 invasor acabou usando apenas o token soVELO com um valor de 1. Quase todos os tokens 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 acabou obtendo grandes lucros.
As etapas específicas são as seguintes:
O invasor executa a quinta transação na proposta e define o fator de empréstimo especificado na proposta.
O atacante empresta 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 invasor. Na função de gancho, o atacante continua a executar a operação de ataque.
O atacante envia os tokens 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 em três vezes pelo atacante).
O atacante cria um novo contrato 0xa16388a6210545b27f669d5189648c1722300b8b. No construtor, ele transfere os 2 tokens soVELO que possui para o 0xa163 de contrato recém-criado (doravante referido como o atacante 0xa163).
O atacante 0xa163 usou os tokens soVELO que detinha para emprestar WETH com um valor de "265.842.857.910.985.546.929" da soWETH.
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 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 na função "exchangeRateStoredInternal", como _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 a taxa de câmbio inicial definida "200.000.000.000.000.000.000.000".
O valor de " redeemTokens " calculado com base na nova taxa de câmbio é " 1.99 ". Devido às características de arredondamento para baixo do 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 ganhou 0xa163 WETH com um valor de "265.842.857.910.985.546.929" emprestado da soWETH.
soVELO.redeemSubjacente:
soVELO.exchangeRateStoredInternal:
O atacante 0xa163 transferiu todos os WETH emprestados e resgatou VELO tokens para o invasor de nível superior e, em seguida, se autodestruiu.
O invasor chama a função "liquidateBorrow" de soWETH para liquidar alguns dos ativos emprestados do contrato recém-criado 0xa163 em ordem para recuperar o token soVELO bloqueado com um valor de 1. Atualmente, o atacante só possui tokens soVELO com um valor de 1.
O invasor chama a função "como" de soVELO e mais uma vez hipoteca e cunha tokens soVELO com o objetivo de coletar 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.
O atacante realiza a operação na etapa 9 várias vezes, paga o empréstimo relâmpago e sai do mercado com lucro.
Como US$ 100 alavancam US$ 6,5 milhões
Após o ataque, o usuário @tonyke_bot no X cunhou 0,00000011 soVELO apostando 1144 tokens VELO no contrato soVELO na transação 0x0a284cd. A razão pela qual esta operação pode impedir o invasor de novos ataques é porque esta transação altera o tamanho de totalSupply em soVELO e o número de tokens de VELO totalCash detidos, e o impacto do crescimento de totalSupply no cálculo de exchangeRate é maior do que o impacto do crescimento de totalCash. Portanto, a taxa de câmbio torna-se menor, fazendo com que o atacante não mais tempo ser capaz de usar a perda de precisão para ganhar soVELO ao realizar um ataque, fazendo com que o ataque não mais tempo possível.
Rastreamento de dinheiro
O atacante transferiu os fundos logo após pegar os recursos ilegais. A maior parte dos recursos foi transferida para os quatro endereços seguintes. Alguns foram para mudar de endereço para continuar o ataque, e outros foram para 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 Ether. Em seguida, alguns fundos foram imediatamente transferidos para o Stargate cadeia cruzada ponte. A maior parte dos fundos ilícitos permanece neste endereço:
3、0xbd18100a168321701955e348f03d0df4f517c13b
O agressor transferiu 33 WETH para esse endereço e usou corrente de descasca para tentar lavar dinheiro. O vínculo de lavagem de dinheiro é o seguinte:
0xbd18100a168321701955e348f03d0df4f517c13b -> 0x7e97b74252b6df53caf386fb4c54d4fb59cb6928 -> 0xc521bde5e53f537ff208970152b75a003 093c2b4 -> 0x9f09ec563222fe52712dc413d0b7b66cb5c7c795。
4、0x4fac0651bcc837bf889f6a7d79c1908419fe1770
O atacante transferiu 563 WETH para este endereço e, posteriormente, para 0x1915F77A116dcE7E9b8F4C4E43CDF81e2aCf9C68, sem nenhuma outra ação até o momento.
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 a auditoria e os 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 (a indústria também abriu gradualmente algumas ferramentas de auditoria de segurança maduras, incluindo 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 revisem cuidadosamente os códigos com perda de precisão no projeto e realizem testes para evitar ao máximo essa vulnerabilidade.
Recomenda-se que a criação de um mercado semelhante ao cToken no Compound e a primeira operação de lançamento de hipoteca sejam realizadas por usuários privilegiados para evitar serem manipulados por invasores e, assim, manipular a taxa exchange.
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.
Isenção de responsabilidade:
- Este artigo foi reproduzido 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 prontamente.
- 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.
- 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.
Artigos relacionados
Introdução à Blockchain de Privacidade Aleo
Lançamento da Babilônia: Repensando o Ecossistema BTCFi