Poly Network subit une attaque de Hacker : une analyse révèle les détails de l'attaque
Récemment, le protocole d'interopérabilité inter-chaînes Poly Network a été attaqué par des hackers, suscitant une large attention dans l'industrie. L'équipe de sécurité a mené une analyse approfondie de cet incident, révélant les méthodes spécifiques des attaquants.
Noyau d'attaque
L'analyse montre que le cœur de cette attaque réside dans la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager. Cette fonction peut exécuter des transactions inter-chaînes spécifiques via la fonction _executeCrossChainTx. L'attaquant a habilement utilisé ce mécanisme pour modifier le rôle clé de keeper dans le système.
Détails de l'attaque
Le propriétaire du contrat EthCrossChainData est le contrat EthCrossChainManager. Cela permet à ce dernier d'appeler la fonction putCurEpochConPubKeyBytes de l'autre, modifiant ainsi le keeper du contrat.
La fonction verifyHeaderAndExecuteTx peut exécuter la transaction inter-chaînes spécifiée par l'utilisateur en appelant en interne la fonction _executeCrossChainTx.
L'attaquant passe des données soigneusement élaborées via la fonction verifyHeaderAndExecuteTx, ce qui provoque l'exécution de la fonction _executeCrossChainTx qui appelle la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData, changeant ainsi le rôle de keeper pour l'adresse spécifiée par l'attaquant.
Une fois que l'adresse du rôle de keeper a été remplacée avec succès, l'attaquant peut alors construire des transactions à sa guise et retirer n'importe quel montant de fonds du contrat.
Impact d'attaque
Après l'attaque, en raison de la modification du keeper, les transactions normales des autres utilisateurs ont été refusées. Cette attaque a non seulement affecté la chaîne BSC, mais des opérations similaires se sont également produites sur le réseau Ethereum.
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, dont la fonction verifyHeaderAndExecuteTx peut exécuter les données fournies par l'utilisateur. L'attaquant a justement exploité cette faille de conception en construisant des données spécifiques pour modifier le keeper, et non par la fuite de la clé privée du keeper comme cela avait été précédemment suggéré.
Cet événement met à nouveau en évidence l'importance de la sécurité des contrats intelligents, en particulier dans les systèmes complexes impliquant des opérations inter-chaînes. Les développeurs doivent concevoir la structure des permissions des contrats avec plus de prudence et effectuer des audits de sécurité complets pour prévenir la survenance d'attaques similaires.
Voir l'original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
7 J'aime
Récompense
7
4
Partager
Commentaire
0/400
WealthCoffee
· 07-04 02:21
Il y a trop de vulnérabilités dans le contrat ??
Voir l'originalRépondre0
LayerZeroHero
· 07-03 15:57
Revoir le site de pertes massives
Voir l'originalRépondre0
LiquidityWizard
· 07-03 15:53
rekt af... en parlant statistiquement, les vulnérabilités cross-chain étaient prévisibles à 73,4 %
Voir l'originalRépondre0
PaperHandsCriminal
· 07-03 15:44
Encore une fois, le contrat a été percé, c'est trop difficile à supporter.
Détails de l'attaque de hacker de Poly Network : la vulnérabilité d'EthCrossChainManager comme clé
Poly Network subit une attaque de Hacker : une analyse révèle les détails de l'attaque
Récemment, le protocole d'interopérabilité inter-chaînes Poly Network a été attaqué par des hackers, suscitant une large attention dans l'industrie. L'équipe de sécurité a mené une analyse approfondie de cet incident, révélant les méthodes spécifiques des attaquants.
Noyau d'attaque
L'analyse montre que le cœur de cette attaque réside dans la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager. Cette fonction peut exécuter des transactions inter-chaînes spécifiques via la fonction _executeCrossChainTx. L'attaquant a habilement utilisé ce mécanisme pour modifier le rôle clé de keeper dans le système.
Détails de l'attaque
Le propriétaire du contrat EthCrossChainData est le contrat EthCrossChainManager. Cela permet à ce dernier d'appeler la fonction putCurEpochConPubKeyBytes de l'autre, modifiant ainsi le keeper du contrat.
La fonction verifyHeaderAndExecuteTx peut exécuter la transaction inter-chaînes spécifiée par l'utilisateur en appelant en interne la fonction _executeCrossChainTx.
L'attaquant passe des données soigneusement élaborées via la fonction verifyHeaderAndExecuteTx, ce qui provoque l'exécution de la fonction _executeCrossChainTx qui appelle la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData, changeant ainsi le rôle de keeper pour l'adresse spécifiée par l'attaquant.
Une fois que l'adresse du rôle de keeper a été remplacée avec succès, l'attaquant peut alors construire des transactions à sa guise et retirer n'importe quel montant de fonds du contrat.
Impact d'attaque
Après l'attaque, en raison de la modification du keeper, les transactions normales des autres utilisateurs ont été refusées. Cette attaque a non seulement affecté la chaîne BSC, mais des opérations similaires se sont également produites sur le réseau Ethereum.
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, dont la fonction verifyHeaderAndExecuteTx peut exécuter les données fournies par l'utilisateur. L'attaquant a justement exploité cette faille de conception en construisant des données spécifiques pour modifier le keeper, et non par la fuite de la clé privée du keeper comme cela avait été précédemment suggéré.
Cet événement met à nouveau en évidence l'importance de la sécurité des contrats intelligents, en particulier dans les systèmes complexes impliquant des opérations inter-chaînes. Les développeurs doivent concevoir la structure des permissions des contrats avec plus de prudence et effectuer des audits de sécurité complets pour prévenir la survenance d'attaques similaires.