Análise do ataque de reentrada de Empréstimos Flash no projeto Jarvis Network
No dia 15 de janeiro de 2023, o projeto Jarvis_Network foi atacado, resultando na perda de 663,101 MATIC. Através da análise da pilha de chamadas das transações de ataque, foi descoberta uma lógica de reentrada. Durante o processo de reentrada, a mesma função de um mesmo contrato foi chamada com os mesmos parâmetros, mas os valores de retorno apresentaram diferenças enormes.
A reentrada ocorre na função remove_liquidity. Esta função devolve os tokens adicionados pelo usuário ao remover liquidez. Como o Polygon é isomórfico ao EVM, a transferência de MATIC para o contrato irá acionar a reentrada.
Uma análise aprofundada revelou que o problema está na implementação da função getUnderlyingPrice. Essa função envolve múltiplas chamadas de contratos, afetando, em última instância, o valor de retorno da função get_virtual_price. O valor de retorno da função get_virtual_price é influenciado pela variável self.D, cuja atualização ocorre após a transferência.
Quando o atacante remove a liquidez, o MATIC é transferido para o contrato do atacante e a função de fallback é chamada para consultar o preço. Como a atualização de self.D ocorre após a transferência, isso resulta em um erro na obtenção do preço anterior. O fluxo do método de remoção de liquidez é: 1) destrói o LP do usuário; 2) envia os fundos apostados do usuário; 3) atualiza self.D.
self.D é usado para cálculos de preço e também será atualizado ao adicionar liquidez. O capital de liquidez do atacante é relativamente grande, e em condições normais o valor de self.D seria muito menor. No entanto, o atacante realiza uma reentrada no passo 2 e empresta a um preço 10 vezes superior ao preço original. Isso ocorre porque o valor de self.D aumenta ao adicionar liquidez, mas não é atualizado a tempo ao remover liquidez.
Embora o método remove_liquidity utilize @nonreentrant( 'lock' ) para evitar reentrâncias, o atacante reentrou em outros contratos para tomar emprestado fundos, tornando o bloqueio de reentrada ineficaz.
A principal razão para o ataque foi a lógica de modificação de variáveis após a chamada externa, o que causou anomalias na obtenção de preços. A reentrada entre contratos fez com que o bloqueio de reentrada falhasse. Recomenda-se que a equipe do projeto realize uma auditoria de segurança rigorosa, coloque a modificação de variáveis antes da chamada externa e adote um método de obtenção de preços de múltiplas fontes de dados. Seguir a norma de codificação "primeiro verificar, depois escrever a variável, e em seguida realizar a chamada externa" (Checks-Effects-Interactions) pode aumentar a segurança e a estabilidade do projeto.
Ver original
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
9 gostos
Recompensa
9
6
Partilhar
Comentar
0/400
All-InQueen
· 08-05 00:42
Blockchain novamente à vista de uma explosão, fiquei paralisado.
Ver originalResponder0
HalfBuddhaMoney
· 08-02 05:37
Não consigo aproveitar tanto assim...
Ver originalResponder0
ZeroRushCaptain
· 08-02 05:37
Outro morreu, a poupança total foi toda pelo ralo, Sam Altman, vamos lá!
Ver originalResponder0
ForkLibertarian
· 08-02 05:29
Mão tão lenta, a perda de corte e puxar o tapete já estão atrasados.
Ver originalResponder0
StakeTillRetire
· 08-02 05:24
Mais um desastre de reentrada. Fiquei isolado.
Ver originalResponder0
SighingCashier
· 08-02 05:13
Perdeu a mão, não foi? É mais uma falha de reentrada.
A Jarvis Network sofreu um ataque de reentrada de Empréstimos Flash, resultando em uma perda de 663.101 MATIC.
Análise do ataque de reentrada de Empréstimos Flash no projeto Jarvis Network
No dia 15 de janeiro de 2023, o projeto Jarvis_Network foi atacado, resultando na perda de 663,101 MATIC. Através da análise da pilha de chamadas das transações de ataque, foi descoberta uma lógica de reentrada. Durante o processo de reentrada, a mesma função de um mesmo contrato foi chamada com os mesmos parâmetros, mas os valores de retorno apresentaram diferenças enormes.
A reentrada ocorre na função remove_liquidity. Esta função devolve os tokens adicionados pelo usuário ao remover liquidez. Como o Polygon é isomórfico ao EVM, a transferência de MATIC para o contrato irá acionar a reentrada.
Uma análise aprofundada revelou que o problema está na implementação da função getUnderlyingPrice. Essa função envolve múltiplas chamadas de contratos, afetando, em última instância, o valor de retorno da função get_virtual_price. O valor de retorno da função get_virtual_price é influenciado pela variável self.D, cuja atualização ocorre após a transferência.
Quando o atacante remove a liquidez, o MATIC é transferido para o contrato do atacante e a função de fallback é chamada para consultar o preço. Como a atualização de self.D ocorre após a transferência, isso resulta em um erro na obtenção do preço anterior. O fluxo do método de remoção de liquidez é: 1) destrói o LP do usuário; 2) envia os fundos apostados do usuário; 3) atualiza self.D.
self.D é usado para cálculos de preço e também será atualizado ao adicionar liquidez. O capital de liquidez do atacante é relativamente grande, e em condições normais o valor de self.D seria muito menor. No entanto, o atacante realiza uma reentrada no passo 2 e empresta a um preço 10 vezes superior ao preço original. Isso ocorre porque o valor de self.D aumenta ao adicionar liquidez, mas não é atualizado a tempo ao remover liquidez.
Embora o método remove_liquidity utilize @nonreentrant( 'lock' ) para evitar reentrâncias, o atacante reentrou em outros contratos para tomar emprestado fundos, tornando o bloqueio de reentrada ineficaz.
A principal razão para o ataque foi a lógica de modificação de variáveis após a chamada externa, o que causou anomalias na obtenção de preços. A reentrada entre contratos fez com que o bloqueio de reentrada falhasse. Recomenda-se que a equipe do projeto realize uma auditoria de segurança rigorosa, coloque a modificação de variáveis antes da chamada externa e adote um método de obtenção de preços de múltiplas fontes de dados. Seguir a norma de codificação "primeiro verificar, depois escrever a variável, e em seguida realizar a chamada externa" (Checks-Effects-Interactions) pode aumentar a segurança e a estabilidade do projeto.