Analyse de l'incident de l'attaque de 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. Selon l'analyse de l'équipe de sécurité, cette attaque n'est pas due à la fuite de la clé privée du keeper, mais plutôt à l'attaquant qui a utilisé des données astucieusement construites pour modifier l'adresse du keeper du contrat EthCrossChainData en exploitant une vulnérabilité du contrat.
Principe de l'attaque
Le cœur 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. Comme 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 utilise la fonction verifyHeaderAndExecuteTx, en passant des données soigneusement conçues, pour exécuter l'appel à la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData via la fonction _executeCrossChainTx, modifiant ainsi le rôle de keeper à l'adresse spécifiée par l'attaquant. Une fois le remplacement de l'adresse du keeper effectué, l'attaquant peut construire des transactions et retirer à sa guise n'importe quel montant de fonds du contrat.
Processus d'attaque
L'attaquant appelle d'abord la fonction putCurEpochConPubKeyBytes via la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager, pour changer le keeper.
Après que le keeper a été modifié, 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é refusées.
Ce mode d'attaque a également des opérations similaires sur le réseau Ethereum.
Résumé
La clé de cette attaque réside dans le fait que le keeper du contrat EthCrossChainData peut être modifié par le contrat EthCrossChainManager, et que la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager peut exécuter les données saisies par l'utilisateur via la fonction _executeCrossChainTx. L'attaquant a justement utilisé cela, en construisant des données spécifiques, pour réussir à modifier le keeper du contrat EthCrossChainData en une adresse contrôlée par l'attaquant.
Cet événement nous rappelle une fois de plus l'importance de prêter une attention particulière à la gestion des droits et à la sécurité des appels de fonctions lors de la conception de contrats intelligents. Pour les fonctions susceptibles d'affecter des paramètres critiques, des contrôles d'accès et des mécanismes de vérification de sécurité plus stricts devraient être mis en œuvre. Parallèlement, la sécurité des projets inter-chaînes nécessite également plus d'attention, car ils impliquent souvent des montants importants et des logiques d'interaction complexes.
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.
21 J'aime
Récompense
21
3
Partager
Commentaire
0/400
GasFeeCrier
· 07-11 15:43
Encore une fois, les smart contracts échouent. C'est vraiment nul.
Voir l'originalRépondre0
SleepTrader
· 07-11 02:54
Encore une fois, une sagesse rétrospective sur l'audit de sécurité.
Poly Network a été attaqué : une vulnérabilité des smart contracts a entraîné la modification du keeper
Analyse de l'incident de l'attaque de 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. Selon l'analyse de l'équipe de sécurité, cette attaque n'est pas due à la fuite de la clé privée du keeper, mais plutôt à l'attaquant qui a utilisé des données astucieusement construites pour modifier l'adresse du keeper du contrat EthCrossChainData en exploitant une vulnérabilité du contrat.
Principe de l'attaque
Le cœur 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. Comme 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 utilise la fonction verifyHeaderAndExecuteTx, en passant des données soigneusement conçues, pour exécuter l'appel à la fonction putCurEpochConPubKeyBytes du contrat EthCrossChainData via la fonction _executeCrossChainTx, modifiant ainsi le rôle de keeper à l'adresse spécifiée par l'attaquant. Une fois le remplacement de l'adresse du keeper effectué, l'attaquant peut construire des transactions et retirer à sa guise n'importe quel montant de fonds du contrat.
Processus d'attaque
L'attaquant appelle d'abord la fonction putCurEpochConPubKeyBytes via la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager, pour changer le keeper.
Après que le keeper a été modifié, 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é refusées.
Ce mode d'attaque a également des opérations similaires sur le réseau Ethereum.
Résumé
La clé de cette attaque réside dans le fait que le keeper du contrat EthCrossChainData peut être modifié par le contrat EthCrossChainManager, et que la fonction verifyHeaderAndExecuteTx du contrat EthCrossChainManager peut exécuter les données saisies par l'utilisateur via la fonction _executeCrossChainTx. L'attaquant a justement utilisé cela, en construisant des données spécifiques, pour réussir à modifier le keeper du contrat EthCrossChainData en une adresse contrôlée par l'attaquant.
Cet événement nous rappelle une fois de plus l'importance de prêter une attention particulière à la gestion des droits et à la sécurité des appels de fonctions lors de la conception de contrats intelligents. Pour les fonctions susceptibles d'affecter des paramètres critiques, des contrôles d'accès et des mécanismes de vérification de sécurité plus stricts devraient être mis en œuvre. Parallèlement, la sécurité des projets inter-chaînes nécessite également plus d'attention, car ils impliquent souvent des montants importants et des logiques d'interaction complexes.