Análise do incidente de ataque Hacker à Poly Network
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network sofreu um ataque de Hacker, o que gerou ampla atenção na indústria. Após análise da equipe de segurança, concluiu-se que este ataque não foi causado pela divulgação da chave privada do keeper, mas sim que os atacantes utilizaram dados inteligentemente construídos para modificar o endereço do keeper do contrato EthCrossChainData através de uma vulnerabilidade no contrato.
Princípio do ataque
O cerne 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 utiliza a função verifyHeaderAndExecuteTx, passando dados cuidadosamente projetados, para fazer com que a função _executeCrossChainTx chame a função putCurEpochConPubKeyBytes do contrato EthCrossChainData, alterando assim o papel do keeper para o endereço especificado pelo atacante. Após a substituição do endereço do keeper, o atacante pode construir transações e retirar arbitrariamente qualquer quantidade 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 keeper.
Depois que o keeper foi alterado, o atacante começou a implementar uma série de transações de ataque para extrair fundos do contrato.
Após o ataque, devido à modificação do keeper, as transações normais de outros usuários foram rejeitadas.
Este padrão de ataque também tem operações semelhantes na rede Ethereum.
Resumo
O ponto chave 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 inputados pelo usuário através da função _executeCrossChainTx. Os atacantes aproveitaram esta vulnerabilidade, conseguindo modificar o keeper do contrato EthCrossChainData para um endereço controlado pelo atacante, ao construir dados específicos.
Este evento lembra-nos novamente que, ao projetar contratos inteligentes, é necessário prestar atenção especial à gestão de permissões e à segurança das chamadas de funções. Para funções que podem afetar parâmetros críticos, devem ser implementados controles de acesso e mecanismos de verificação de segurança mais rigorosos. Ao mesmo tempo, a segurança dos projetos de cross-chain também precisa de mais atenção, uma vez que frequentemente envolvem grandes quantidades de fundos e lógicas de interação complexas.
Ver original
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.
21 Curtidas
Recompensa
21
3
Compartilhar
Comentário
0/400
GasFeeCrier
· 07-11 15:43
Outra vez contratos inteligentes falhando. Que fraco!
Ver originalResponder0
SleepTrader
· 07-11 02:54
Outra Lição aprendida a posteriori de auditoria de segurança
Poly Network foi atacado: o erro nos contratos inteligentes levou à alteração do keeper
Análise do incidente de ataque Hacker à Poly Network
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network sofreu um ataque de Hacker, o que gerou ampla atenção na indústria. Após análise da equipe de segurança, concluiu-se que este ataque não foi causado pela divulgação da chave privada do keeper, mas sim que os atacantes utilizaram dados inteligentemente construídos para modificar o endereço do keeper do contrato EthCrossChainData através de uma vulnerabilidade no contrato.
Princípio do ataque
O cerne 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 utiliza a função verifyHeaderAndExecuteTx, passando dados cuidadosamente projetados, para fazer com que a função _executeCrossChainTx chame a função putCurEpochConPubKeyBytes do contrato EthCrossChainData, alterando assim o papel do keeper para o endereço especificado pelo atacante. Após a substituição do endereço do keeper, o atacante pode construir transações e retirar arbitrariamente qualquer quantidade 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 keeper.
Depois que o keeper foi alterado, o atacante começou a implementar uma série de transações de ataque para extrair fundos do contrato.
Após o ataque, devido à modificação do keeper, as transações normais de outros usuários foram rejeitadas.
Este padrão de ataque também tem operações semelhantes na rede Ethereum.
Resumo
O ponto chave 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 inputados pelo usuário através da função _executeCrossChainTx. Os atacantes aproveitaram esta vulnerabilidade, conseguindo modificar o keeper do contrato EthCrossChainData para um endereço controlado pelo atacante, ao construir dados específicos.
Este evento lembra-nos novamente que, ao projetar contratos inteligentes, é necessário prestar atenção especial à gestão de permissões e à segurança das chamadas de funções. Para funções que podem afetar parâmetros críticos, devem ser implementados controles de acesso e mecanismos de verificação de segurança mais rigorosos. Ao mesmo tempo, a segurança dos projetos de cross-chain também precisa de mais atenção, uma vez que frequentemente envolvem grandes quantidades de fundos e lógicas de interação complexas.