L'attaque de Platypus a exploité un ordre incorrect du code, selon un auditeur
L’attaque de prêt flash Platypus de 8 millions de dollars a été rendue possible grâce à un code qui était dans le mauvais ordre. La société d’audit affirme que le code problématique n’existait pas dans la version qu’elle a vue.
//t.co/30PzcoIJnt a préparé une analyse technique post-mortem décrivant comment l’exploit s’est déroulé dans les moindres détails.
//t.co/cf784QtKPK
Selon le rapport, le contrat Platypus MasterPlatypusV4 « contenait une idée fausse fatale dans son mécanisme de retrait d’urgence » qui l’obligeait à effectuer « son contrôle de solvabilité avant de mettre à jour les jetons LP associés à la position de participation ».
Le rapport soulignait que le code de la fonction emergencyWithdraw contenait tous les éléments nécessaires pour empêcher une attaque, mais ces éléments étaient simplement écrits dans le mauvais ordre, comme l’a expliqué Omniscia :
« Le problème aurait pu être évité en réordonnant les instructions MasterPlatypusV4 ::emergencyWithdraw et en effectuant le contrôle de solvabilité après que l’entrée du montant de l’utilisateur ait été définie sur 0, ce qui aurait interdit l’attaque. »
Omnisia a admis avoir audité une version du contrat MasterPlatypusV4 du 21 novembre au 5 décembre 2021. Cependant, cette version « ne contenait aucun point d’intégration avec un système platypusTreasure externe » et ne contenait donc pas les lignes de code mal ordonnées. Du point de vue d’Omniscia, cela implique que les développeurs doivent avoir déployé une nouvelle version du contrat à un moment donné après la réalisation de l’audit.
En rapport: Raydium annonce les détails du piratage et propose une indemnisation pour les victimes
L’auditeur affirme que la mise en œuvre du contrat à l’adresse C-Chain d’Avalanche (AVAX) est celle qui a été exploitée. Les lignes 582-584 de ce contrat semblent appeler une fonction appelée « isSolvent » sur le contrat PlatypusTreasure, et les lignes 599-601 semblent définir le montant, le facteur et la récompenseDebt de l’utilisateur à zéro. Cependant, ces quantités sont mises à zéro après que la fonction « isSolvent » ait déjà été appelée.
L’équipe de Platypus a confirmé le 16 février que l’attaquant avait exploité une « faille dans Mécanisme de contrôle de solvabilité USP », mais l’équipe n’a initialement pas fourni plus de détails. Ce nouveau rapport de l’auditeur apporte un éclairage supplémentaire sur la façon dont l’attaquant a pu accomplir l’exploit.
L’attaquant a utilisé des prêts flashés pour exécuter l’exploit, qui est similaire à la stratégie utilisée dans l’exploit Defrost Finance du 25 décembre.
