Análise de Vulnerabilidades de Segurança da Poly Network: Como os atacantes exploram as falhas do contrato para alterar permissões
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network sofreu um grave incidente de segurança, gerando ampla atenção no setor. De acordo com análises de especialistas em segurança, este ataque não foi causado por vazamento de chave privada, mas sim pela exploração habilidosa de uma vulnerabilidade em um contrato inteligente.
O núcleo do evento reside na falha de design da função verifyHeaderAndExecuteTx do contrato EthCrossChainManager. Essa função pode executar transações cross-chain especificadas pelo usuário através da função interna _executeCrossChainTx. Os atacantes exploraram isso, construindo dados específicos que fazem com que a função _executeCrossChainTx chame a função putCurEpochConPubKeyBytes do contrato EthCrossChainData, alterando assim o papel de keeper para um endereço controlado pelo atacante.
O processo de ataque específico é o seguinte:
O atacante chama primeiro a função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, passando os dados cuidadosamente construídos.
A função interna executa _executeCrossChainTx, que chama a função putCurEpochConPubKeyBytes do contrato EthCrossChainData.
A função putCurEpochConPubKeyBytes é executada, alterando o endereço do papel de keeper para o endereço especificado pelo atacante.
Após a substituição do keeper, o atacante obteve permissões de operação e pode construir transações à vontade para retirar fundos do contrato.
Após o ataque, devido à modificação do keeper, as transações normais de outros usuários começam a ser recusadas.
Esta técnica de ataque foi utilizada tanto na cadeia BSC quanto na cadeia Ethereum. A chave do ataque está no fato de que o keeper do contrato EthCrossChainData pode ser modificado pelo contrato EthCrossChainManager, que por sua vez permite a execução de quaisquer dados fornecidos pelo usuário. Este design apresenta sérias vulnerabilidades de segurança, oferecendo uma oportunidade para os atacantes.
Este evento demonstra mais uma vez que a segurança dos contratos inteligentes é crucial. As equipes de desenvolvimento devem considerar cuidadosamente vários cenários de ataque ao projetar contratos, restringindo rigorosamente os direitos de chamada das funções-chave e realizando auditorias de segurança abrangentes. Ao mesmo tempo, os projetos descentralizados também precisam estabelecer mecanismos de governança mais completos para lidar com situações de emergência.
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.
17 Curtidas
Recompensa
17
8
Compartilhar
Comentário
0/400
FomoAnxiety
· 07-21 14:29
Ser enganado por idiotas
Ver originalResponder0
airdrop_whisperer
· 07-20 03:50
Outra vulnerabilidade em contratos inteligentes
Ver originalResponder0
blocksnark
· 07-18 15:43
Outra vez é culpa dos contratos inteligentes
Ver originalResponder0
NFT_Therapy
· 07-18 15:40
Clássico entre clássicos, mais um contratos inteligentes que falhou.
Ver originalResponder0
BTCRetirementFund
· 07-18 15:37
Mais uma vez o contrato foi explorado?
Ver originalResponder0
MemeKingNFT
· 07-18 15:33
Mais um dia visitado pelo ladrão divino, o mundo das artes marciais é como uma grande onda que separa o joio do trigo, vamos ver de quem é o contrato que ainda não tem brechas.
Análise de vulnerabilidades dos contratos inteligentes da Poly Network: como os atacantes alteraram o papel de keeper para obter fundos
Análise de Vulnerabilidades de Segurança da Poly Network: Como os atacantes exploram as falhas do contrato para alterar permissões
Recentemente, o protocolo de interoperabilidade entre cadeias Poly Network sofreu um grave incidente de segurança, gerando ampla atenção no setor. De acordo com análises de especialistas em segurança, este ataque não foi causado por vazamento de chave privada, mas sim pela exploração habilidosa de uma vulnerabilidade em um contrato inteligente.
O núcleo do evento reside na falha de design da função verifyHeaderAndExecuteTx do contrato EthCrossChainManager. Essa função pode executar transações cross-chain especificadas pelo usuário através da função interna _executeCrossChainTx. Os atacantes exploraram isso, construindo dados específicos que fazem com que a função _executeCrossChainTx chame a função putCurEpochConPubKeyBytes do contrato EthCrossChainData, alterando assim o papel de keeper para um endereço controlado pelo atacante.
O processo de ataque específico é o seguinte:
O atacante chama primeiro a função verifyHeaderAndExecuteTx do contrato EthCrossChainManager, passando os dados cuidadosamente construídos.
A função interna executa _executeCrossChainTx, que chama a função putCurEpochConPubKeyBytes do contrato EthCrossChainData.
A função putCurEpochConPubKeyBytes é executada, alterando o endereço do papel de keeper para o endereço especificado pelo atacante.
Após a substituição do keeper, o atacante obteve permissões de operação e pode construir transações à vontade para retirar fundos do contrato.
Após o ataque, devido à modificação do keeper, as transações normais de outros usuários começam a ser recusadas.
Esta técnica de ataque foi utilizada tanto na cadeia BSC quanto na cadeia Ethereum. A chave do ataque está no fato de que o keeper do contrato EthCrossChainData pode ser modificado pelo contrato EthCrossChainManager, que por sua vez permite a execução de quaisquer dados fornecidos pelo usuário. Este design apresenta sérias vulnerabilidades de segurança, oferecendo uma oportunidade para os atacantes.
Este evento demonstra mais uma vez que a segurança dos contratos inteligentes é crucial. As equipes de desenvolvimento devem considerar cuidadosamente vários cenários de ataque ao projetar contratos, restringindo rigorosamente os direitos de chamada das funções-chave e realizando auditorias de segurança abrangentes. Ao mesmo tempo, os projetos descentralizados também precisam estabelecer mecanismos de governança mais completos para lidar com situações de emergência.