Le projet aBNBc a été attaqué par des hackers, une vulnérabilité du contrat a conduit à l'émission illégale d'un grand nombre de jetons.

Récemment, un projet nommé aBNBc a subi une attaque de hacker, entraînant l'émission illégale d'un grand nombre de jetons. Selon les données off-chain, les attaquants ont exploité une faille de contrat pour émettre massivement des jetons aBNBc et ont échangé une partie contre des BNB, tandis qu'une partie restante est toujours conservée dans un portefeuille. De plus, le hacker a également transféré des fonds via un service de crypto tumbler anonyme. Cet incident a entraîné l'épuisement du pool de liquidité des jetons aBNBc, avec une chute significative du prix des jetons, et en raison de l'utilisation par les attaquants des jetons nouvellement émis pour des prêts garantis, cela a également causé des pertes aux plateformes de prêt concernées.

Après avoir analysé plusieurs données de transaction, il a été constaté que, bien que l'appelant ait utilisé différentes adresses, cela a conduit à une émission excessive de jetons. Des enquêtes supplémentaires montrent que le projet venait de subir une mise à niveau de contrat juste avant l'attaque, et que la fonction d'émission excessive dans le nouveau contrat logique manquait de vérifications de droits nécessaires.

Après l'attaque, l'équipe du projet a rapidement agi et a mis à jour le contrat logique. La nouvelle version du contrat a ajouté un mécanisme de vérification des autorisations pour la fonction d'augmentation de l'émission, afin d'empêcher que des événements similaires ne se reproduisent.

Concernant les flux de fonds, il est actuellement connu que des hackers ont échangé une partie des aBNBc émis contre des BNB et les ont transférés, tandis qu'une grande quantité d'aBNBc reste encore dans leur portefeuille.

La principale raison de cet incident d'attaque est le manque de vérification des autorisations dans la fonction d'émission supplémentaire du nouveau contrat logique lors de la mise à niveau du contrat. Il n'est pas encore clair si un code de contrat non audité et non testé a été utilisé, ou si la fuite de la clé privée a conduit le Hacker à mettre à niveau le contrat de manière autonome. Quoi qu'il en soit, cet incident rappelle à nouveau aux utilisateurs et aux projets de bien garder leurs clés privées et leurs phrases de récupération, afin d'éviter de les stocker de manière aléatoire. En outre, lors de la mise à niveau des contrats, il est impératif de réaliser des tests de sécurité complets.