Análise do ataque de reentrada de empréstimos flash no projeto Jarvis Network

Dados mostram que em 15 de janeiro de 2023 às 17:43:37 UTC, o projeto Jarvis_Network foi atacado, resultando na perda de 663,101 MATIC.

Analisando a pilha de chamadas de transações, descobrimos que existe lógica de reentrada no processo de remoção de liquidez. Antes e depois da reentrada, a chamada da mesma função do mesmo contrato, com os mesmos parâmetros, resulta em valores de retorno bastante diferentes:

• Reentrada anterior: 1,002,157,321,772,769,944
• Reentrada: 10,091,002,696,492,234,934

A reentrada ocorre na função remove_liquidity. Esta função devolve os tokens adicionados pelo usuário ao remover liquidez. Como Polygon e EVM são cadeias homólogas, a transferência de MATIC para o contrato acionará a reentrada do contrato.

Uma análise aprofundada revela que o problema está na implementação da função getUnderlyingPrice. Esta função envolve uma série de cálculos internos e chamadas externas, sendo que o ponto chave é o valor de retorno da função get_virtual_price.

O valor de retorno da função get_virtual_price é afetado pela variável self.D. Na função remove_liquidity, a atualização de self.D ocorre após a transferência dos tokens. O atacante, ao remover liquidez, transfere MATIC para o contrato de ataque, e durante a chamada de fallback, consulta primeiro o preço do token. Como self.D ainda não foi atualizado, isso resulta em um erro na obtenção do preço.

fluxo da função remove_liquidity:

1. Destruir LP do usuário
2. Enviar fundos de staking do usuário
3. Atualizar self.D

O atacante realiza um reentrada no segundo passo, utilizando um valor self.D não atualizado para o empréstimo, obtendo 10 vezes o capital do preço normal.

Embora a função remove_liquidity utilize @nonreentrant('lock') para evitar reentrâncias, um atacante conseguiu contornar esse mecanismo de proteção através de reentrâncias entre contratos.

Este ataque expôs várias questões-chave:

1. A lógica de modificação de variáveis após a chamada externa leva a anomalias na obtenção do preço.
2. A reentrada entre contratos torna o bloqueio de reentrada ineficaz
3. Não seguir o padrão "Verificações-Efeitos-Interações" (Checks-Effects-Interactions)

Para aumentar a segurança, a equipe do projeto deve:

• Realizar auditorias de segurança rigorosas
• Coloque a modificação da variável antes da chamada externa
• Utiliza múltiplas fontes de dados para obtenção de preços
• Seguir a norma de codificação "primeiro avaliar, depois escrever na variável, e por fim fazer a chamada externa"

Com estas medidas, é possível aumentar significativamente a segurança e a estabilidade do projeto, prevenindo eficazmente ataques semelhantes.