aBNBc a été attaqué par des hackers, une négligence dans la mise à niveau du contrat a entraîné l'émission illégale d'un grand nombre de jetons.

Le 2 décembre, un laboratoire a découvert par le biais de données on-chain que le projet aBNBc avait été victime d'une attaque de hacker, entraînant une émission illégale d'un grand nombre de jetons aBNBc. Le hacker a échangé une partie des jetons nouvellement émis contre des BNB sur un DEX, tandis qu'une autre partie a été conservée dans un portefeuille. De plus, les attaquants ont également utilisé ces jetons émis illégalement pour des prêts garantis, causant des pertes à la plateforme de prêt. Cet incident a entraîné une grave insuffisance de liquidité pour le jeton aBNBc, avec une chute de son prix.

En analysant plusieurs données de transactions, les chercheurs ont découvert que, bien que les adresses d'appel soient différentes, elles ont toutes conduit à une émission supplémentaire de jetons. Des enquêtes supplémentaires ont montré que le projet avait effectué une mise à jour de contrat avant d'être attaqué, et que la fonction d'émission supplémentaire dans le contrat logique mis à jour manquait de vérifications d'autorisation nécessaires.

Un hacker a appelé une fonction spécifique dans le contrat logique via un contrat d'agent. Étant donné que cette fonction n'a pas effectué de vérification des autorisations, l'émission illégale de jetons aBNBc a été réalisée avec succès.

Après avoir été attaqué, l'équipe du projet a immédiatement mis à jour le contrat logique, ajoutant un mécanisme de vérification des permissions pour la fonction d'émission dans la nouvelle version.

En ce qui concerne les flux de fonds, le Hacker a échangé une partie des aBNBc émis en trop contre des BNB et les a transférés, mais une grande quantité d'aBNBc reste toujours dans son Portefeuille.

Dans l'ensemble, cette attaque provient principalement d'une négligence lors du processus de mise à niveau du contrat, à savoir que la fonction d'émission dans le nouveau contrat logique manquait de vérifications de permissions nécessaires. Il n'est pas encore clair si cela est dû à l'utilisation d'un code de contrat non audité et non testé pour la sécurité, ou si c'est à cause d'une fuite de clé privée qui a permis à un hacker de mettre à jour le contrat de manière autonome. Quoi qu'il en soit, cet incident souligne à nouveau l'importance de bien protéger les clés privées et les phrases mnémotechniques du portefeuille, ainsi que la nécessité de réaliser des tests de sécurité complets lors des mises à niveau de contrat.