Une vulnérabilité de contrat d'un certain projet a entraîné une émission massive de jetons. Un hacker a piégé des BNB, provoquant des turbulences sur le marché.
Le 2 décembre, selon les données de surveillance on-chain, un projet a subi une attaque de Hacker, entraînant l'émission illégale d'un grand nombre de jetons. Les attaquants ont échangé une partie des BNB sur un DEX avec les jetons émis, tandis que le reste a été conservé dans un Portefeuille. De plus, le Hacker a également utilisé un service de transfert anonyme pour effectuer un transfert de fonds. Cet incident a entraîné l'épuisement du pool de liquidité de ce jeton, le prix du jeton a chuté considérablement, et en raison de l'utilisation des jetons émis pour le prêt garanti, cela a également causé des pertes à la plateforme de prêt.
Après avoir analysé de nombreuses données de transactions, il a été constaté que, bien si les appelants utilisaient des adresses différentes, cela a tous entraîné une augmentation de l'émission des jetons. Une enquête plus approfondie a révélé que le projet avait effectué une mise à jour du contrat avant d'être attaqué, et que la fonction d'augmentation de l'émission dans le nouveau contrat logique n'avait pas subi les vérifications de permission nécessaires.
L'attaquant a appelé une fonction spécifique dans le contrat logique via un contrat proxy. En raison de l'absence de vérification des autorisations dans cette fonction, cela a entraîné une émission illégale de jetons. Après l'attaque, l'équipe du projet a rapidement mis à jour le contrat logique, ajoutant un mécanisme de vérification des autorisations à la fonction d'émission.
Actuellement, les hackers ont échangé une partie des jetons émis illégalement contre du BNB et les ont transférés, mais il reste encore une grande quantité de jetons émis illégalement dans leur portefeuille.
La cause fondamentale de cette attaque réside dans le fait que lors de la mise à jour du contrat, la fonction d'émission du nouveau contrat logique manquait de vérifications d'autorisation nécessaires. Il n'est pas encore clair si cela est dû à l'utilisation de code de contrat non audité et non testé pour la sécurité, ou si une fuite de clé privée a permis au hacker de mettre à jour le contrat de lui-même. Quoi qu'il en soit, cet événement rappelle à nouveau aux utilisateurs et aux projets l'importance de protéger correctement les clés privées et les phrases de récupération du portefeuille, tout en soulignant la nécessité de réaliser des tests de sécurité complets lors de la mise à jour des contrats.
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.
12 J'aime
Récompense
12
5
Partager
Commentaire
0/400
SchroedingerAirdrop
· Il y a 6h
Encore une fois, j'ai tondu des pigeons.
Voir l'originalRépondre0
GasFeeNightmare
· Il y a 7h
Encore une fois, les smart contracts causent des problèmes !
Voir l'originalRépondre0
TokenToaster
· Il y a 7h
Encore un piège de détection des autorisations, gm
Voir l'originalRépondre0
Token_Sherpa
· Il y a 7h
cas classique d'élasticité de l'offre qui tourne mal... encore un autre système ponzinomique qui s'effondre pour être honnête.
Voir l'originalRépondre0
CountdownToBroke
· Il y a 7h
Encore des pigeons pris pour des idiots et qui font un Rug Pull.
Une vulnérabilité de contrat d'un certain projet a entraîné une émission massive de jetons. Un hacker a piégé des BNB, provoquant des turbulences sur le marché.
Le 2 décembre, selon les données de surveillance on-chain, un projet a subi une attaque de Hacker, entraînant l'émission illégale d'un grand nombre de jetons. Les attaquants ont échangé une partie des BNB sur un DEX avec les jetons émis, tandis que le reste a été conservé dans un Portefeuille. De plus, le Hacker a également utilisé un service de transfert anonyme pour effectuer un transfert de fonds. Cet incident a entraîné l'épuisement du pool de liquidité de ce jeton, le prix du jeton a chuté considérablement, et en raison de l'utilisation des jetons émis pour le prêt garanti, cela a également causé des pertes à la plateforme de prêt.
Après avoir analysé de nombreuses données de transactions, il a été constaté que, bien si les appelants utilisaient des adresses différentes, cela a tous entraîné une augmentation de l'émission des jetons. Une enquête plus approfondie a révélé que le projet avait effectué une mise à jour du contrat avant d'être attaqué, et que la fonction d'augmentation de l'émission dans le nouveau contrat logique n'avait pas subi les vérifications de permission nécessaires.
L'attaquant a appelé une fonction spécifique dans le contrat logique via un contrat proxy. En raison de l'absence de vérification des autorisations dans cette fonction, cela a entraîné une émission illégale de jetons. Après l'attaque, l'équipe du projet a rapidement mis à jour le contrat logique, ajoutant un mécanisme de vérification des autorisations à la fonction d'émission.
Actuellement, les hackers ont échangé une partie des jetons émis illégalement contre du BNB et les ont transférés, mais il reste encore une grande quantité de jetons émis illégalement dans leur portefeuille.
La cause fondamentale de cette attaque réside dans le fait que lors de la mise à jour du contrat, la fonction d'émission du nouveau contrat logique manquait de vérifications d'autorisation nécessaires. Il n'est pas encore clair si cela est dû à l'utilisation de code de contrat non audité et non testé pour la sécurité, ou si une fuite de clé privée a permis au hacker de mettre à jour le contrat de lui-même. Quoi qu'il en soit, cet événement rappelle à nouveau aux utilisateurs et aux projets l'importance de protéger correctement les clés privées et les phrases de récupération du portefeuille, tout en soulignant la nécessité de réaliser des tests de sécurité complets lors de la mise à jour des contrats.