Análise do incidente de ataque do Hacker à Poly Network
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network sofreu um ataque de Hacker, gerando ampla atenção. Após uma análise aprofundada pela equipe de segurança, ficou claro que o atacante não realizou o ataque através da divulgação da chave privada do keeper, mas explorou uma vulnerabilidade no contrato.
Princípio do Ataque
O núcleo do ataque reside na função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, que pode executar transações específicas entre cadeias através da função _executeCrossChainTx. Como o proprietário do contrato EthCrossChainData é o contrato EthCrossChainManager, este último pode chamar a função putCurEpochConPubKeyBytes do primeiro para modificar o keeper do contrato.
O atacante, ao passar dados cuidadosamente elaborados para a função verifyHeaderAndExecuteTx, fez com que a função _executeCrossChainTx executasse uma chamada à função putCurEpochConPubKeyBytes do contrato EthCrossChainData, alterando assim o papel de keeper para um endereço especificado pelo atacante. Após a substituição do papel de keeper, o atacante pode construir transações à vontade e retirar qualquer quantidade de fundos do contrato.
Processo de Ataque
O atacante primeiro chamou a função putCurEpochConPubKeyBytes através da função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, alterando o keeper.
Em seguida, o hacker utilizou as permissões alteradas para realizar uma série de transações de ataque, extraindo fundos do contrato.
Devido à modificação do keeper, as transações normais de outros usuários foram rejeitadas.
Este padrão de ataque não ocorre apenas na rede BSC, mas também na rede Ethereum ocorreram operações de ataque semelhantes.
Conclusão
A causa fundamental deste incidente de 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 inseridos pelo usuário através da função _executeCrossChainTx. O atacante explorou essa falha de design, modificando o keeper do contrato EthCrossChainData ao construir dados específicos, e assim conseguiu roubar fundos.
Este evento destaca novamente a importância do design de segurança dos protocolos de cross-chain, especialmente no que diz respeito à gestão de permissões e à necessidade de uma auditoria e restrições mais rigorosas nas chamadas de funções. Para projetos de finanças descentralizadas, auditorias de segurança contínuas e correções de vulnerabilidades são essenciais para prevenir a ocorrência de ataques semelhantes.
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.
18 gostos
Recompensa
18
6
Republicar
Partilhar
Comentar
0/400
PanicSeller69
· 08-12 04:32
Vulnerabilidade ainda faz o quê no defí?
Ver originalResponder0
BearMarketNoodler
· 08-11 11:12
Mais uma vítima. Aviso de tutorial para obter algo de graça.
Ver originalResponder0
HodlKumamon
· 08-10 15:50
Ah ah ah, como é que a auditoria QA foi feita tão mal ~
Ver originalResponder0
AirdropATM
· 08-10 15:49
As falhas nos contratos são realmente irritantes
Ver originalResponder0
TokenCreatorOP
· 08-10 15:46
又被锤 ser liquidado 了嘛
Ver originalResponder0
PoolJumper
· 08-10 15:31
Depois de ter sido tão explorado, o contrato ainda se atreve a falar de falhas?
Poly Network foi atacado por hackers: uma vulnerabilidade no contrato levou à alteração do keeper
Análise do incidente de ataque do Hacker à Poly Network
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network sofreu um ataque de Hacker, gerando ampla atenção. Após uma análise aprofundada pela equipe de segurança, ficou claro que o atacante não realizou o ataque através da divulgação da chave privada do keeper, mas explorou uma vulnerabilidade no contrato.
Princípio do Ataque
O núcleo do ataque reside na função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, que pode executar transações específicas entre cadeias através da função _executeCrossChainTx. Como o proprietário do contrato EthCrossChainData é o contrato EthCrossChainManager, este último pode chamar a função putCurEpochConPubKeyBytes do primeiro para modificar o keeper do contrato.
O atacante, ao passar dados cuidadosamente elaborados para a função verifyHeaderAndExecuteTx, fez com que a função _executeCrossChainTx executasse uma chamada à função putCurEpochConPubKeyBytes do contrato EthCrossChainData, alterando assim o papel de keeper para um endereço especificado pelo atacante. Após a substituição do papel de keeper, o atacante pode construir transações à vontade e retirar qualquer quantidade de fundos do contrato.
Processo de Ataque
O atacante primeiro chamou a função putCurEpochConPubKeyBytes através da função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, alterando o keeper.
Em seguida, o hacker utilizou as permissões alteradas para realizar uma série de transações de ataque, extraindo fundos do contrato.
Devido à modificação do keeper, as transações normais de outros usuários foram rejeitadas.
Este padrão de ataque não ocorre apenas na rede BSC, mas também na rede Ethereum ocorreram operações de ataque semelhantes.
Conclusão
A causa fundamental deste incidente de 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 inseridos pelo usuário através da função _executeCrossChainTx. O atacante explorou essa falha de design, modificando o keeper do contrato EthCrossChainData ao construir dados específicos, e assim conseguiu roubar fundos.
Este evento destaca novamente a importância do design de segurança dos protocolos de cross-chain, especialmente no que diz respeito à gestão de permissões e à necessidade de uma auditoria e restrições mais rigorosas nas chamadas de funções. Para projetos de finanças descentralizadas, auditorias de segurança contínuas e correções de vulnerabilidades são essenciais para prevenir a ocorrência de ataques semelhantes.