Analyse détaillée de l'attaque de Hacker sur Poly Network
Récemment, le protocole d'interopérabilité entre chaînes Poly Network a subi une attaque de hacker, suscitant une large attention. L'équipe de sécurité a mené une analyse approfondie de cet événement et estime que les attaquants ont modifié le rôle de keeper du contrat EthCrossChainData par le biais de données soigneusement élaborées, et non par la fuite de la clé privée du keeper comme cela avait été précédemment prétendu.
Coeur de l'attaque
La clé de l'attaque réside dans la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager, qui peut exécuter des transactions inter-chaînes spécifiques via la fonction _executeCrossChainTx. Étant donné que le propriétaire du contrat EthCrossChainData est le contrat EthCrossChainManager, ce dernier peut appeler la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData pour modifier le keeper du contrat.
L'attaquant n'a qu'à passer des données soigneusement conçues via la fonction verifyHeaderAndExecuteTx pour exécuter un appel à la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData, permettant ainsi de changer le rôle de keeper pour l'adresse spécifiée par l'attaquant. Une fois le remplacement de l'adresse du rôle de keeper effectué, l'attaquant peut construire des transactions à sa guise et retirer n'importe quel montant de fonds du contrat.
Processus d'attaque
L'attaquant commence par appeler la fonction putCurEpochConPubKeyBytes via la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager, modifiant ainsi le rôle de keeper.
Ensuite, l'attaquant a commencé à mettre en œuvre une série de transactions d'attaque pour extraire des fonds du contrat.
Après l'attaque, en raison de la modification du keeper, les transactions normales des autres utilisateurs sont refusées.
Des techniques d'attaque similaires ont également été mises en œuvre sur le réseau Ethereum, le processus étant similaire à celui des attaques sur BSC.
Conclusion
La cause fondamentale de cette attaque réside dans le fait que le keeper du contrat EthCrossChainData peut être modifié par le contrat EthCrossChainManager, tandis que la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager peut exécuter les données saisies par l'utilisateur via la fonction _executeCrossChainTx. L'attaquant a exploité cette vulnérabilité en construisant des données spécifiques, réussissant ainsi à changer le keeper du contrat EthCrossChainData en une adresse qu'il contrôle, permettant ainsi le retrait illégal des fonds du contrat.
Cet événement souligne à nouveau l'importance des audits de sécurité des contrats intelligents, en particulier dans les systèmes complexes impliquant des opérations inter-chaînes et la gestion de rôles clés. Les équipes de développement doivent concevoir et mettre en œuvre des mécanismes de gestion des droits des contrats avec plus de prudence, afin d'éviter que des vulnérabilités de sécurité similaires ne soient exploitées.
Voir l'original
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
4 J'aime
Récompense
4
4
Partager
Commentaire
0/400
ChainWanderingPoet
· Il y a 10h
Encore hacké ? Le contrat peut encore être maintenu.
Analyse approfondie de l'attaque de hacker de Poly Network : le rôle de keeper du contrat EthCrossChainData a été altéré.
Analyse détaillée de l'attaque de Hacker sur Poly Network
Récemment, le protocole d'interopérabilité entre chaînes Poly Network a subi une attaque de hacker, suscitant une large attention. L'équipe de sécurité a mené une analyse approfondie de cet événement et estime que les attaquants ont modifié le rôle de keeper du contrat EthCrossChainData par le biais de données soigneusement élaborées, et non par la fuite de la clé privée du keeper comme cela avait été précédemment prétendu.
Coeur de l'attaque
La clé de l'attaque réside dans la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager, qui peut exécuter des transactions inter-chaînes spécifiques via la fonction _executeCrossChainTx. Étant donné que le propriétaire du contrat EthCrossChainData est le contrat EthCrossChainManager, ce dernier peut appeler la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData pour modifier le keeper du contrat.
L'attaquant n'a qu'à passer des données soigneusement conçues via la fonction verifyHeaderAndExecuteTx pour exécuter un appel à la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData, permettant ainsi de changer le rôle de keeper pour l'adresse spécifiée par l'attaquant. Une fois le remplacement de l'adresse du rôle de keeper effectué, l'attaquant peut construire des transactions à sa guise et retirer n'importe quel montant de fonds du contrat.
Processus d'attaque
L'attaquant commence par appeler la fonction putCurEpochConPubKeyBytes via la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager, modifiant ainsi le rôle de keeper.
Ensuite, l'attaquant a commencé à mettre en œuvre une série de transactions d'attaque pour extraire des fonds du contrat.
Après l'attaque, en raison de la modification du keeper, les transactions normales des autres utilisateurs sont refusées.
Des techniques d'attaque similaires ont également été mises en œuvre sur le réseau Ethereum, le processus étant similaire à celui des attaques sur BSC.
Conclusion
La cause fondamentale de cette attaque réside dans le fait que le keeper du contrat EthCrossChainData peut être modifié par le contrat EthCrossChainManager, tandis que la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager peut exécuter les données saisies par l'utilisateur via la fonction _executeCrossChainTx. L'attaquant a exploité cette vulnérabilité en construisant des données spécifiques, réussissant ainsi à changer le keeper du contrat EthCrossChainData en une adresse qu'il contrôle, permettant ainsi le retrait illégal des fonds du contrat.
Cet événement souligne à nouveau l'importance des audits de sécurité des contrats intelligents, en particulier dans les systèmes complexes impliquant des opérations inter-chaînes et la gestion de rôles clés. Les équipes de développement doivent concevoir et mettre en œuvre des mécanismes de gestion des droits des contrats avec plus de prudence, afin d'éviter que des vulnérabilités de sécurité similaires ne soient exploitées.