Análise do incidente de ataque de reentrada do OrionProtocol
No dia 2 de fevereiro de 2023, o OrionProtocol na Ethereum e na Binance Smart Chain sofreu um ataque de reentrada devido a uma vulnerabilidade no contrato, resultando em uma perda total de cerca de 2,9 milhões de dólares, incluindo 2.844.766 USDT na Ethereum e 191.606 BUSD na BSC.
Análise do Processo de Ataque
Os atacantes primeiro implantaram um contrato de Token personalizado e realizaram operações de transferência e autorização, preparando-se para o ataque subsequente. Em seguida, os atacantes realizaram um empréstimo através do método swap de um DEX e chamaram o método ExchangeWithAtomic.swapThroughOrionPool para a troca de tokens. O caminho de troca foi definido como USDC → Token do atacante → USDT.
Durante a execução do método ExchangeWithAtomic.swapThroughOrionPool, devido à existência de uma função de callback no contrato Token do atacante, o método ExchangeWithAtomic.depositAsset foi chamado novamente durante o processo de Token.Transfer, resultando em um ataque de reentrada. Isso fez com que o montante do depósito fosse acumulado várias vezes, permitindo que o atacante obtivesse lucros excessivos através da operação de retirada.
Fluxo de Capital
Os fundos iniciais do atacante vêm de uma carteira quente de uma plataforma de negociação. Dos 1.651 ETH obtidos com o ataque, 657,5 ainda permanecem no endereço da carteira do atacante, enquanto o restante foi transferido através de serviços de mistura.
Análise de Vulnerabilidades
A vulnerabilidade central existe nas funções doSwapThroughOrionPool e _doSwapTokens. O problema chave é que o contrato atualiza a variável curBalance apenas após a transferência de tokens, o que cria condições para um ataque de reentrada. O atacante adiciona lógica de callback na função transfer do Token personalizado, fazendo com que a função depositAsset seja chamada novamente durante o processo de transferência, resultando na atualização incorreta de curBalance.
Reproduzindo a Falha
Os pesquisadores forneceram parte do código POC, simulando o processo de ataque. Os resultados dos testes mostraram que o atacante conseguiu explorar a vulnerabilidade para obter USDT adicional.
Sugestões de Segurança
Durante o desenvolvimento de contratos, deve-se seguir rigorosamente o padrão "Verificações-Efeitos-Interações" (Checks-Effects-Interactions), ou seja, primeiro realizar a verificação de estado, em seguida atualizar o estado do contrato e por último interagir com contratos externos.
Ao implementar a funcionalidade de troca de tokens, é necessário considerar os riscos de segurança que podem advir de múltiplos tokens e caminhos de troca.
Para funções críticas que envolvem operações financeiras, deve-se implementar um lock de reentrada ou utilizar bibliotecas de segurança como o ReentrancyGuard da OpenZeppelin.
Realizar auditorias de código e avaliações de segurança regularmente, para identificar e corrigir vulnerabilidades potenciais de forma oportuna.
Considerar a introdução de mecanismos como limites de montante de transação ou bloqueios de tempo para reduzir as perdas que um ataque único pode causar.
Ao adotar essas medidas, a equipe do projeto pode efetivamente aumentar a segurança dos contratos inteligentes e reduzir o risco de sofrer ataques semelhantes.
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
3
Compartilhar
Comentário
0/400
ContractFreelancer
· 16h atrás
Outra vez um ataque de reentrada, que chato.
Ver originalResponder0
GasFeeCry
· 16h atrás
Então, estão a dar dinheiro aos hackers novamente.
OrionProtocol sofreu um ataque de reentrada, perda de 2,9 milhões de dólares, análise das recomendações de segurança.
Análise do incidente de ataque de reentrada do OrionProtocol
No dia 2 de fevereiro de 2023, o OrionProtocol na Ethereum e na Binance Smart Chain sofreu um ataque de reentrada devido a uma vulnerabilidade no contrato, resultando em uma perda total de cerca de 2,9 milhões de dólares, incluindo 2.844.766 USDT na Ethereum e 191.606 BUSD na BSC.
Análise do Processo de Ataque
Os atacantes primeiro implantaram um contrato de Token personalizado e realizaram operações de transferência e autorização, preparando-se para o ataque subsequente. Em seguida, os atacantes realizaram um empréstimo através do método swap de um DEX e chamaram o método ExchangeWithAtomic.swapThroughOrionPool para a troca de tokens. O caminho de troca foi definido como USDC → Token do atacante → USDT.
Durante a execução do método ExchangeWithAtomic.swapThroughOrionPool, devido à existência de uma função de callback no contrato Token do atacante, o método ExchangeWithAtomic.depositAsset foi chamado novamente durante o processo de Token.Transfer, resultando em um ataque de reentrada. Isso fez com que o montante do depósito fosse acumulado várias vezes, permitindo que o atacante obtivesse lucros excessivos através da operação de retirada.
Fluxo de Capital
Os fundos iniciais do atacante vêm de uma carteira quente de uma plataforma de negociação. Dos 1.651 ETH obtidos com o ataque, 657,5 ainda permanecem no endereço da carteira do atacante, enquanto o restante foi transferido através de serviços de mistura.
Análise de Vulnerabilidades
A vulnerabilidade central existe nas funções doSwapThroughOrionPool e _doSwapTokens. O problema chave é que o contrato atualiza a variável curBalance apenas após a transferência de tokens, o que cria condições para um ataque de reentrada. O atacante adiciona lógica de callback na função transfer do Token personalizado, fazendo com que a função depositAsset seja chamada novamente durante o processo de transferência, resultando na atualização incorreta de curBalance.
Reproduzindo a Falha
Os pesquisadores forneceram parte do código POC, simulando o processo de ataque. Os resultados dos testes mostraram que o atacante conseguiu explorar a vulnerabilidade para obter USDT adicional.
Sugestões de Segurança
Durante o desenvolvimento de contratos, deve-se seguir rigorosamente o padrão "Verificações-Efeitos-Interações" (Checks-Effects-Interactions), ou seja, primeiro realizar a verificação de estado, em seguida atualizar o estado do contrato e por último interagir com contratos externos.
Ao implementar a funcionalidade de troca de tokens, é necessário considerar os riscos de segurança que podem advir de múltiplos tokens e caminhos de troca.
Para funções críticas que envolvem operações financeiras, deve-se implementar um lock de reentrada ou utilizar bibliotecas de segurança como o ReentrancyGuard da OpenZeppelin.
Realizar auditorias de código e avaliações de segurança regularmente, para identificar e corrigir vulnerabilidades potenciais de forma oportuna.
Considerar a introdução de mecanismos como limites de montante de transação ou bloqueios de tempo para reduzir as perdas que um ataque único pode causar.
Ao adotar essas medidas, a equipe do projeto pode efetivamente aumentar a segurança dos contratos inteligentes e reduzir o risco de sofrer ataques semelhantes.