Análise do ataque de reentrada de Empréstimos Flash na Jarvis Network

Recentemente, um projeto chamado Jarvis_Network sofreu um ataque de reentrada de Empréstimos Flash, resultando na perda de cerca de 663 mil tokens MATIC. Este incidente ocorreu na noite de 15 de janeiro de 2023.

Através de uma análise aprofundada da pilha de chamadas de transações, descobrimos que o atacante explorou uma vulnerabilidade de reentrada. Durante o processo de reentrada, a mesma função do mesmo contrato foi chamada várias vezes, mas os valores de retorno de cada chamada apresentaram grandes diferenças. Essa diferença manifesta-se principalmente na função remove_liquidity.

O ataque de reentrada ocorre durante o processo de remoção de liquidez. Como Polygon e EVM são cadeias homogêneas, quando MATIC é transferido para o contrato, a lógica de reentrada do contrato é ativada. Através de uma análise detalhada da pilha de chamadas, descobrimos que o problema está na função getUnderlyingPrice.

Uma investigação mais aprofundada revelou que o atacante explorou uma falha no momento da atualização da variável self.D ao remover a liquidez. Normalmente, o fluxo do método remove_liquidity deveria ser: 1) destruir o LP do usuário; 2) enviar os fundos de staking ao usuário; 3) atualizar self.D. No entanto, o atacante realizou uma operação de reentrada na segunda etapa, resultando em um erro grave no cálculo do preço.

Apesar de a função remove_liquidity usar o decorador @nonreentrant('lock') para prevenir reentrâncias, o bloqueio de reentrância não teve efeito, pois o atacante reentrou em outros contratos para pegar fundos emprestados.

Este ataque expôs principalmente dois problemas:

1. A lógica de modificação da variável está localizada após a chamada externa, levando a uma anomalia na obtenção do preço.
2. A reentrada entre contratos faz com que o bloqueio de reentrada fique ineficaz.

Para evitar ataques semelhantes, recomenda-se que as partes do projeto adotem as seguintes medidas:

1. Certifique-se de que o código passou por uma auditoria de segurança rigorosa.
2. Coloque a modificação da variável antes da chamada externa.
3. Utilizar múltiplas fontes de dados para obter preços.
4. Seguir a norma de codificação "primeiro verificar, depois escrever em variáveis, e então realizar chamadas externas" (Checks-Effects-Interactions).

Ao adotar essas medidas, o projeto pode aumentar significativamente sua segurança e estabilidade, proporcionando serviços mais confiáveis aos usuários.