Análise detalhada do ataque do Hacker à Poly Network
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network foi alvo de um ataque hacker, gerando ampla atenção. A equipe de segurança analisou o evento em profundidade e acredita que os atacantes modificaram o papel de keeper do contrato EthCrossChainData através de dados cuidadosamente elaborados, e não devido à suposta vazamento da chave privada do keeper, como rumores anteriores sugeriam.
Ataque ao Núcleo
A chave do ataque reside na função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, que pode executar transações específicas de cross-chain através da função _executeCrossChainTx. Como o proprietário do contrato EthCrossChainData é o contrato EthCrossChainManager, este pode chamar a função putCurEpochConPubKeyBytes do contrato EthCrossChainData para modificar o keeper do contrato.
O atacante só precisa passar dados cuidadosamente projetados através da função verifyHeaderAndExecuteTx, permitindo a execução da chamada da função putCurEpochConPubKeyBytes do contrato EthCrossChainData pela função _executeCrossChainTx, alterando assim o papel de keeper para o endereço especificado pelo atacante. Após a conclusão da substituição do endereço do papel de keeper, o atacante pode construir transações à vontade, retirando qualquer quantia de fundos do contrato.
Processo de Ataque
O atacante primeiro chama a função putCurEpochConPubKeyBytes através da função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, alterando o papel do keeper.
Em seguida, o hacker começou a implementar uma série de transações de ataque, retirando fundos do contrato.
Após o ataque, devido à modificação do keeper, as transações normais de outros usuários foram recusadas.
Métodos de ataque semelhantes também foram implementados na rede Ethereum, e o processo é semelhante ao ataque na BSC.
Conclusão
A causa fundamental deste ataque reside no fato de que o keeper do contrato EthCrossChainData pode ser modificado pelo contrato EthCrossChainManager, e a função verifyHeaderAndExecuteTx do contrato EthCrossChainManager pode executar os dados de entrada do usuário através da função _executeCrossChainTx. O atacante explorou esta vulnerabilidade, construindo dados específicos, e conseguiu alterar o keeper do contrato EthCrossChainData para um endereço sob seu controle, permitindo a retirada ilegal de fundos do contrato.
Este evento enfatiza novamente a importância da auditoria de segurança de contratos inteligentes, especialmente em sistemas complexos que envolvem operações cross-chain e gestão de papéis críticos. As equipas de desenvolvimento devem ser mais cautelosas ao projetar e implementar mecanismos de gestão de permissões de contratos, para evitar que vulnerabilidades de segurança semelhantes sejam exploradas.
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.
4 gostos
Recompensa
4
4
Partilhar
Comentar
0/400
ChainWanderingPoet
· 14h atrás
Novamente hackeado? O contrato ainda pode sustentar.
Análise Profunda do Ataque Hacker à Poly Network: O papel do keeper do contrato EthCrossChainData foi alterado.
Análise detalhada do ataque do Hacker à Poly Network
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network foi alvo de um ataque hacker, gerando ampla atenção. A equipe de segurança analisou o evento em profundidade e acredita que os atacantes modificaram o papel de keeper do contrato EthCrossChainData através de dados cuidadosamente elaborados, e não devido à suposta vazamento da chave privada do keeper, como rumores anteriores sugeriam.
Ataque ao Núcleo
A chave do ataque reside na função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, que pode executar transações específicas de cross-chain através da função _executeCrossChainTx. Como o proprietário do contrato EthCrossChainData é o contrato EthCrossChainManager, este pode chamar a função putCurEpochConPubKeyBytes do contrato EthCrossChainData para modificar o keeper do contrato.
O atacante só precisa passar dados cuidadosamente projetados através da função verifyHeaderAndExecuteTx, permitindo a execução da chamada da função putCurEpochConPubKeyBytes do contrato EthCrossChainData pela função _executeCrossChainTx, alterando assim o papel de keeper para o endereço especificado pelo atacante. Após a conclusão da substituição do endereço do papel de keeper, o atacante pode construir transações à vontade, retirando qualquer quantia de fundos do contrato.
Processo de Ataque
O atacante primeiro chama a função putCurEpochConPubKeyBytes através da função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, alterando o papel do keeper.
Em seguida, o hacker começou a implementar uma série de transações de ataque, retirando fundos do contrato.
Após o ataque, devido à modificação do keeper, as transações normais de outros usuários foram recusadas.
Métodos de ataque semelhantes também foram implementados na rede Ethereum, e o processo é semelhante ao ataque na BSC.
Conclusão
A causa fundamental deste ataque reside no fato de que o keeper do contrato EthCrossChainData pode ser modificado pelo contrato EthCrossChainManager, e a função verifyHeaderAndExecuteTx do contrato EthCrossChainManager pode executar os dados de entrada do usuário através da função _executeCrossChainTx. O atacante explorou esta vulnerabilidade, construindo dados específicos, e conseguiu alterar o keeper do contrato EthCrossChainData para um endereço sob seu controle, permitindo a retirada ilegal de fundos do contrato.
Este evento enfatiza novamente a importância da auditoria de segurança de contratos inteligentes, especialmente em sistemas complexos que envolvem operações cross-chain e gestão de papéis críticos. As equipas de desenvolvimento devem ser mais cautelosas ao projetar e implementar mecanismos de gestão de permissões de contratos, para evitar que vulnerabilidades de segurança semelhantes sejam exploradas.