Análise do ataque de reentrada de Empréstimos Flash no projeto Jarvis Network
Recentemente, um ataque ao projeto Jarvis Network chamou a atenção da indústria. De acordo com a monitorização de dados on-chain, o ataque ocorreu em 15 de janeiro de 2023, resultando na perda de 663,101 tokens MATIC pelo projeto.
Através da análise da pilha de chamadas das transações de ataque, descobrimos que o atacante utilizou uma combinação de Empréstimos Flash e vulnerabilidades de reentrada. Durante o processo de retirada de liquidez, o atacante conseguiu implementar um ataque de reentrada, resultando em valores completamente diferentes retornados pela mesma função antes e depois da reentrada.
Cavando mais fundo, verifica-se que o problema está na função remove_liquidity. Esta função é responsável por remover a liquidez e retornar os tokens do usuário. Como a cadeia Polygon é compatível com EVM, a lógica de reentrada do contrato é acionada durante o processo de transferência.
A vulnerabilidade chave reside na variável self.D utilizada no cálculo de preços. Normalmente, self.D deve ser atualizado em tempo útil ao remover liquidez. No entanto, devido a uma falha na lógica do código, a atualização de self.D foi adiada para depois da chamada externa. Isso deu aos atacantes a oportunidade de inserir operações no meio, aproveitando o valor não atualizado de self.D para arbitragem.
Embora a função remove_liquidity utilize o decorador @nonreentrant('lock') para prevenir reentradas, os atacantes conseguiram contornar essa proteção de forma astuta. Eles conseguiram reentrar em funcionalidades de empréstimo de outros contratos, em vez de reentrar diretamente na própria função remove_liquidity, evitando assim as restrições do bloqueio de reentradas.
Este ataque destacou a importância de vários princípios de segurança fundamentais no desenvolvimento de contratos inteligentes:
Siga rigorosamente o padrão Checks-Effects-Interactions.
Garantir que a atualização das variáveis-chave seja concluída antes de qualquer chamada externa.
Utilizar múltiplas fontes de dados para obter preços, a fim de aumentar a robustez do sistema.
Uma auditoria de segurança abrangente é essencial para encontrar e corrigir potenciais vulnerabilidades.
Este incidente é mais um lembrete de que a segurança é sempre uma prioridade no ecossistema blockchain em rápido crescimento. A equipe de desenvolvimento do projeto deve monitorar continuamente as práticas de segurança mais recentes e realizar revisões regulares de código e testes de vulnerabilidade para garantir a segurança dos ativos do usuário.
Ver original
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.
6 Curtidas
Recompensa
6
7
Compartilhar
Comentário
0/400
MidnightSnapHunter
· 07-18 10:01
Os bugs de contrato são realmente difíceis de evitar.
Jarvis Network sofreu um ataque de reentrada de Empréstimos Flash, com uma perda de 660 mil MATIC tokens.
Análise do ataque de reentrada de Empréstimos Flash no projeto Jarvis Network
Recentemente, um ataque ao projeto Jarvis Network chamou a atenção da indústria. De acordo com a monitorização de dados on-chain, o ataque ocorreu em 15 de janeiro de 2023, resultando na perda de 663,101 tokens MATIC pelo projeto.
Através da análise da pilha de chamadas das transações de ataque, descobrimos que o atacante utilizou uma combinação de Empréstimos Flash e vulnerabilidades de reentrada. Durante o processo de retirada de liquidez, o atacante conseguiu implementar um ataque de reentrada, resultando em valores completamente diferentes retornados pela mesma função antes e depois da reentrada.
Cavando mais fundo, verifica-se que o problema está na função remove_liquidity. Esta função é responsável por remover a liquidez e retornar os tokens do usuário. Como a cadeia Polygon é compatível com EVM, a lógica de reentrada do contrato é acionada durante o processo de transferência.
A vulnerabilidade chave reside na variável self.D utilizada no cálculo de preços. Normalmente, self.D deve ser atualizado em tempo útil ao remover liquidez. No entanto, devido a uma falha na lógica do código, a atualização de self.D foi adiada para depois da chamada externa. Isso deu aos atacantes a oportunidade de inserir operações no meio, aproveitando o valor não atualizado de self.D para arbitragem.
! Análise de Incidentes de Ataque de Re-entrancy de Empréstimo Flash da Rede Jarvis
Embora a função remove_liquidity utilize o decorador @nonreentrant('lock') para prevenir reentradas, os atacantes conseguiram contornar essa proteção de forma astuta. Eles conseguiram reentrar em funcionalidades de empréstimo de outros contratos, em vez de reentrar diretamente na própria função remove_liquidity, evitando assim as restrições do bloqueio de reentradas.
Este ataque destacou a importância de vários princípios de segurança fundamentais no desenvolvimento de contratos inteligentes:
! Análise de Incidentes de Ataque de Re-entrancy de Empréstimo Flash da Rede Jarvis
Este incidente é mais um lembrete de que a segurança é sempre uma prioridade no ecossistema blockchain em rápido crescimento. A equipe de desenvolvimento do projeto deve monitorar continuamente as práticas de segurança mais recentes e realizar revisões regulares de código e testes de vulnerabilidade para garantir a segurança dos ativos do usuário.