Análise do incidente de ataque na cadeia de 300 mil dólares causado por vulnerabilidades de armazenamento temporário
No dia 30 de março de 2025, um projeto de negociação alavancada na cadeia Ethereum sofreu um ataque, resultando em uma perda de mais de 300 mil dólares em ativos. A equipe de segurança realizou uma análise aprofundada deste evento e agora compartilha os resultados a seguir:
Conhecimento de Fundo
A versão 0.8.24 do Solidity introduziu a funcionalidade de (transient storage), que é um novo local de armazenamento de dados. As principais características incluem:
Baixo custo de gas: o custo de gas das operações TSTORE e TLOAD é fixo em 100.
Persistência dentro da transação: os dados permanecem válidos durante toda a transação.
Limpeza automática: Após o término da transação, o armazenamento transitório é automaticamente redefinido para zero.
Motivo do ataque
A causa fundamental deste evento é que os valores armazenados temporariamente usando tstore na função não foram limpos após o término da chamada da função. Os atacantes aproveitaram essa característica para construir endereços maliciosos específicos que contornam a verificação de permissões, permitindo assim a transferência de tokens.
Passos do ataque
O atacante cria dois tokens maliciosos A e B, e cria pools de liquidez para esses dois tokens em um DEX.
O atacante chama a função initialize do contrato Vault, utilizando o token A como token de colateral e o token B como token de dívida para criar um mercado de negociação alavancada.
O atacante chama a função mint do contrato Vault, depositando o token de dívida B para cunhar o token alavancado. Durante esse processo, o endereço da piscina DEX é armazenado temporariamente pela primeira vez.
Quando a piscina DEX realiza uma operação de troca, chamará a função uniswapV3SwapCallback do contrato Vault. Esta função utiliza tload para verificar a identidade do chamador a partir do armazenamento transitório e armazena a quantidade cunhada em um segundo armazenamento transitório.
O atacante cria um contrato malicioso cujo endereço é igual ao valor armazenado temporariamente na segunda vez.
O atacante chama diretamente a função uniswapV3SwapCallback do contrato Vault através do contrato malicioso para transferir tokens. Devido ao fato de que os valores na memória transitória não foram limpos, a autenticação foi erroneamente aprovada.
Por fim, o atacante chama a função uniswapV3SwapCallback do contrato Vault através do contrato atacado (token A), transferindo outros tokens (como WBTC, WETH) do contrato Vault para obter lucro.
Análise do fluxo de capital
Segundo a análise da ferramenta de combate à lavagem de dinheiro e rastreamento na cadeia, os atacantes roubaram aproximadamente 300 mil dólares em ativos, incluindo:
17,814.8626 USDC
1.4085 WBTC
119.871 WETH
Em seguida, o atacante trocou WBTC e USDC por WETH, totalizando 193,1428 WETH transferidos para uma ferramenta de mistura. A fonte inicial de fundos do atacante foi de 0,3 ETH transferidos da ferramenta de mistura.
Sugestões de segurança
A equipe do projeto deve usar imediatamente o tstore(key, 0) para limpar os valores do armazenamento transitório após o término da chamada de função, de acordo com a lógica de negócios.
Reforçar a auditoria de código de contrato e os testes de segurança, evitando vulnerabilidades semelhantes.
Utilize com cautela as características recentemente introduzidas, compreendendo plenamente os seus riscos potenciais.
Estabelecer um mecanismo de múltipla verificação, não depender apenas de um único método de autenticação.
Realizar avaliações de segurança e varreduras de vulnerabilidades periodicamente, corrigindo prontamente os problemas identificados.
Este incidente de ataque enfatiza novamente a necessidade de os projetos de blockchain serem especialmente cautelosos ao utilizar novas características tecnológicas, ao mesmo tempo que destaca a importância de auditorias de segurança contínuas. Os desenvolvedores devem estar sempre atentos às melhores práticas de segurança mais recentes e seguir rigorosamente na implementação do código.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
14 Curtidas
Recompensa
14
7
Compartilhar
Comentário
0/400
DegenWhisperer
· 20h atrás
Ser enganado por idiotas de uma nova jornada começou.
Ver originalResponder0
PensionDestroyer
· 20h atrás
30w já foi aprimorado
Ver originalResponder0
AirDropMissed
· 20h atrás
又被 fazer as pessoas de parvas uma onda idiotas
Ver originalResponder0
ruggedNotShrugged
· 20h atrás
A mentalidade é pequena. Agora, esses ataques não são nada.
Ver originalResponder0
SillyWhale
· 20h atrás
又有小项目被 fazer as pessoas de parvas idiotas了
Ver originalResponder0
RugPullAlarm
· 20h atrás
Mais um contrato que não foi limpo corretamente e foi exposto.
Ver originalResponder0
SwingingLittleLeek
· 20h atrás
Recentemente, o Ethereum está flutuando acima de 3000! No futuro, continuará acima de 3000.
Vulnerabilidade de armazenamento transitório leva a ataque de 300 mil dólares a projeto Ethereum. Equipe de segurança analisa detalhes chave.
Análise do incidente de ataque na cadeia de 300 mil dólares causado por vulnerabilidades de armazenamento temporário
No dia 30 de março de 2025, um projeto de negociação alavancada na cadeia Ethereum sofreu um ataque, resultando em uma perda de mais de 300 mil dólares em ativos. A equipe de segurança realizou uma análise aprofundada deste evento e agora compartilha os resultados a seguir:
Conhecimento de Fundo
A versão 0.8.24 do Solidity introduziu a funcionalidade de (transient storage), que é um novo local de armazenamento de dados. As principais características incluem:
Motivo do ataque
A causa fundamental deste evento é que os valores armazenados temporariamente usando tstore na função não foram limpos após o término da chamada da função. Os atacantes aproveitaram essa característica para construir endereços maliciosos específicos que contornam a verificação de permissões, permitindo assim a transferência de tokens.
Passos do ataque
O atacante cria dois tokens maliciosos A e B, e cria pools de liquidez para esses dois tokens em um DEX.
O atacante chama a função initialize do contrato Vault, utilizando o token A como token de colateral e o token B como token de dívida para criar um mercado de negociação alavancada.
O atacante chama a função mint do contrato Vault, depositando o token de dívida B para cunhar o token alavancado. Durante esse processo, o endereço da piscina DEX é armazenado temporariamente pela primeira vez.
Quando a piscina DEX realiza uma operação de troca, chamará a função uniswapV3SwapCallback do contrato Vault. Esta função utiliza tload para verificar a identidade do chamador a partir do armazenamento transitório e armazena a quantidade cunhada em um segundo armazenamento transitório.
O atacante cria um contrato malicioso cujo endereço é igual ao valor armazenado temporariamente na segunda vez.
O atacante chama diretamente a função uniswapV3SwapCallback do contrato Vault através do contrato malicioso para transferir tokens. Devido ao fato de que os valores na memória transitória não foram limpos, a autenticação foi erroneamente aprovada.
Por fim, o atacante chama a função uniswapV3SwapCallback do contrato Vault através do contrato atacado (token A), transferindo outros tokens (como WBTC, WETH) do contrato Vault para obter lucro.
Análise do fluxo de capital
Segundo a análise da ferramenta de combate à lavagem de dinheiro e rastreamento na cadeia, os atacantes roubaram aproximadamente 300 mil dólares em ativos, incluindo:
Em seguida, o atacante trocou WBTC e USDC por WETH, totalizando 193,1428 WETH transferidos para uma ferramenta de mistura. A fonte inicial de fundos do atacante foi de 0,3 ETH transferidos da ferramenta de mistura.
Sugestões de segurança
A equipe do projeto deve usar imediatamente o tstore(key, 0) para limpar os valores do armazenamento transitório após o término da chamada de função, de acordo com a lógica de negócios.
Reforçar a auditoria de código de contrato e os testes de segurança, evitando vulnerabilidades semelhantes.
Utilize com cautela as características recentemente introduzidas, compreendendo plenamente os seus riscos potenciais.
Estabelecer um mecanismo de múltipla verificação, não depender apenas de um único método de autenticação.
Realizar avaliações de segurança e varreduras de vulnerabilidades periodicamente, corrigindo prontamente os problemas identificados.
Este incidente de ataque enfatiza novamente a necessidade de os projetos de blockchain serem especialmente cautelosos ao utilizar novas características tecnológicas, ao mesmo tempo que destaca a importância de auditorias de segurança contínuas. Os desenvolvedores devem estar sempre atentos às melhores práticas de segurança mais recentes e seguir rigorosamente na implementação do código.