Analyse de l'incident de l'attaque du Hacker sur Poly Network
Récemment, le protocole d'interopérabilité cross-chain Poly Network a subi une attaque de hacker, suscitant une large attention dans l'industrie. L'équipe de sécurité a effectué une analyse approfondie de cet incident, révélant les détails et le processus spécifiques de l'attaque.
Principe de l'attaque
Le cœur de cette attaque réside dans la vulnérabilité de la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager. L'attaquant a réussi à modifier le keeper du contrat EthCrossChainData en passant des données soigneusement construites à cette fonction, ce qui contredit les affirmations précédentes concernant la fuite de la clé privée du keeper.
L'attaquant a exploité les points clés suivants :
La fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager peut exécuter des transactions inter-chaînes via la fonction _executeCrossChainTx.
Le propriétaire du contrat EthCrossChainData est le contrat EthCrossChainManager, qui peut appeler la fonction putCurEpochConPubKeyBytes de ce dernier pour modifier le keeper.
L'attaquant construit des données spécifiques, en appelant la fonction verifyHeaderAndExecuteTx pour exécuter _executeCrossChainTx, puis exécute la fonction putCurEpochConPubKeyBytes, changeant le keeper pour une adresse contrôlée par l'attaquant.
Après avoir effectué le remplacement du keeper, l'attaquant peut alors construire des transactions à sa guise et extraire n'importe quel montant de fonds du contrat.
Processus d'attaque
L'attaque s'est principalement produite sur les réseaux Binance Smart Chain (BSC) et Ethereum, le processus étant à peu près le même :
L'attaquant appelle d'abord la fonction putCurEpochConPubKeyBytes via la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager pour modifier le keeper.
Après le remplacement du keeper, 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 ont été annulées.
Impact de l'événement
Cette attaque a révélé une faille majeure dans la conception des contrats du protocole Poly Network. L'attaquant a réussi à contourner les mécanismes de sécurité existants en exploitant les relations de droits et les mécanismes d'appel de fonctions entre les contrats. Cet événement met à nouveau en lumière les défis auxquels les protocoles inter-chaînes sont confrontés en matière de sécurité, ainsi que l'importance de l'audit de code et de la conception sécurisée.
Révélation de sécurité
La conception des contrats doit être plus prudente, en particulier en ce qui concerne la gestion des autorisations des rôles clés (comme le keeper).
La sécurité des appels inter-contrats doit être évaluée de manière exhaustive pour éviter l'apparition de vulnérabilités pouvant être exploitées par des hackers.
Effectuer régulièrement des audits de sécurité complets pour détecter et corriger rapidement les risques potentiels.
Établir un mécanisme de validation multiple pour éviter les risques systémiques résultant d'un point de défaillance unique.
Renforcer la surveillance en temps réel et la capacité de réponse aux urgences, afin de réagir rapidement et de prendre les mesures nécessaires en cas d'attaque.
Cet incident a sonné l'alarme pour l'ensemble de l'industrie de la blockchain, rappelant aux développeurs et aux équipes de projet qu'ils doivent toujours placer la sécurité en priorité et continuer à améliorer et optimiser la conception des protocoles.
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.
17 J'aime
Récompense
17
5
Partager
Commentaire
0/400
AlphaBrain
· 07-31 16:42
Vous jouez à la chaîne sans comprendre les contrats ?
Voir l'originalRépondre0
SlowLearnerWang
· 07-31 16:42
Eh bien, c'est encore le moment pour moi de monter à bord... Je disais que les vulnérabilités des contrats sont inévitables.
Voir l'originalRépondre0
SandwichHunter
· 07-31 16:37
Eh bien, encore un bug de contrat, ne le faites pas trop.
Voir l'originalRépondre0
BoredWatcher
· 07-31 16:26
Le plaisir du transfert de contrat est de retour~
Voir l'originalRépondre0
DegenRecoveryGroup
· 07-31 16:17
Qui a encore explosé le contrat ? On peut encore hacker, hein ?
Analyse de la vulnérabilité du contrat EthCrossChainManager dans l'incident de piratage de Poly Network : Révélation.
Analyse de l'incident de l'attaque du Hacker sur Poly Network
Récemment, le protocole d'interopérabilité cross-chain Poly Network a subi une attaque de hacker, suscitant une large attention dans l'industrie. L'équipe de sécurité a effectué une analyse approfondie de cet incident, révélant les détails et le processus spécifiques de l'attaque.
Principe de l'attaque
Le cœur de cette attaque réside dans la vulnérabilité de la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager. L'attaquant a réussi à modifier le keeper du contrat EthCrossChainData en passant des données soigneusement construites à cette fonction, ce qui contredit les affirmations précédentes concernant la fuite de la clé privée du keeper.
L'attaquant a exploité les points clés suivants :
La fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager peut exécuter des transactions inter-chaînes via la fonction _executeCrossChainTx.
Le propriétaire du contrat EthCrossChainData est le contrat EthCrossChainManager, qui peut appeler la fonction putCurEpochConPubKeyBytes de ce dernier pour modifier le keeper.
L'attaquant construit des données spécifiques, en appelant la fonction verifyHeaderAndExecuteTx pour exécuter _executeCrossChainTx, puis exécute la fonction putCurEpochConPubKeyBytes, changeant le keeper pour une adresse contrôlée par l'attaquant.
Après avoir effectué le remplacement du keeper, l'attaquant peut alors construire des transactions à sa guise et extraire n'importe quel montant de fonds du contrat.
Processus d'attaque
L'attaque s'est principalement produite sur les réseaux Binance Smart Chain (BSC) et Ethereum, le processus étant à peu près le même :
L'attaquant appelle d'abord la fonction putCurEpochConPubKeyBytes via la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager pour modifier le keeper.
Après le remplacement du keeper, 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 ont été annulées.
Impact de l'événement
Cette attaque a révélé une faille majeure dans la conception des contrats du protocole Poly Network. L'attaquant a réussi à contourner les mécanismes de sécurité existants en exploitant les relations de droits et les mécanismes d'appel de fonctions entre les contrats. Cet événement met à nouveau en lumière les défis auxquels les protocoles inter-chaînes sont confrontés en matière de sécurité, ainsi que l'importance de l'audit de code et de la conception sécurisée.
Révélation de sécurité
La conception des contrats doit être plus prudente, en particulier en ce qui concerne la gestion des autorisations des rôles clés (comme le keeper).
La sécurité des appels inter-contrats doit être évaluée de manière exhaustive pour éviter l'apparition de vulnérabilités pouvant être exploitées par des hackers.
Effectuer régulièrement des audits de sécurité complets pour détecter et corriger rapidement les risques potentiels.
Établir un mécanisme de validation multiple pour éviter les risques systémiques résultant d'un point de défaillance unique.
Renforcer la surveillance en temps réel et la capacité de réponse aux urgences, afin de réagir rapidement et de prendre les mesures nécessaires en cas d'attaque.
Cet incident a sonné l'alarme pour l'ensemble de l'industrie de la blockchain, rappelant aux développeurs et aux équipes de projet qu'ils doivent toujours placer la sécurité en priorité et continuer à améliorer et optimiser la conception des protocoles.