Aller au contenu
Fondé MMXXVIVol. VI · № 273RSS
Blockchain Breaches

Archive des incidents de sécurité dans les cryptomonnaies — piratages, exploits, défaillances de ponts et rug pulls, documentés avec des preuves on-chain.

Dossier № 130Bug de smart contract

Vidage par burn public de SafeMoon

SafeMoon a perdu 8,9 M$ de son pool WBNB après qu'une mise à niveau a laissé burn() public, permettant de brûler les SFM des autres et drainer WBNB.

Date
Victime
SafeMoon
Chaîne(s)
Statut
Partiellement récupéré

Le 28 mars 2023, la memecoin promue par Jake Paul SafeMoon a perdu environ 8,9 millions de dollars de son pool de liquidité WBNB lorsqu'un attaquant a exploité une fonction burn() publique accidentellement exposée dans une récente mise à niveau de contrat. La fonction permettait à tout utilisateur de brûler des jetons depuis toute autre adresse — y compris le pool de liquidité WBNB SafeMoon lui-même. Après négociation, l'attaquant a restitué 7 M$ (80%).

Ce qui s'est passé

Une mise à niveau du contrat SafeMoon a introduit une fonction burn() avec des permissions d'accès publiques — presque certainement une conséquence non intentionnelle d'un refactor qui était censé laisser la fonction comme une opération admin interne. La fonction permettait à tout appelant de spécifier toute adresse et de brûler les jetons SFM depuis le solde de cette adresse, sans vérification d'autorisation.

L'analyse de PeckShield a noté le schéma de mise à niveau et a caractérisé le bug comme probablement lié à une fuite de clé admin — quelqu'un avec l'autorité de mise à niveau semble avoir poussé la version public-burn du contrat, soit par compromission, soit par une erreur de développeur qui n'a pas été détectée dans la revue.

L'attaque :

  1. Identification de la fonction burn() publique dans le nouveau contrat.
  2. Brûlage de la majorité des jetons SFM détenus par le pool de liquidité WBNB/SFM — réduisant drastiquement l'offre de SFM dans le pool tout en laissant le WBNB inchangé.
  3. Le mécanisme de découverte automatique des prix du pool a interprété la réduction de l'offre comme une énorme flambée de prix dans SFM — parce que le même WBNB devait maintenant être tarifé contre une minuscule offre de SFM.
  4. Vente d'une petite quantité de SFM dans le pool au prix artificiellement gonflé, drainant la majorité du WBNB du pool en échange.
  5. Départ avec environ 8,9 M$ en WBNB.

Conséquences

  • L'équipe SafeMoon a alerté la communauté en quelques heures et engagé l'attaquant via des messages on-chain.
  • L'attaquant a restitué 7 M$ (80% des fonds volés) après négociation, gardant 2 M$ comme « prime » effective.
  • SafeMoon a mis en pause les contrats affectés et livré un jeton redessiné avec des contrôles d'accès appropriés.
  • L'épisode a contribué au dénouement plus large du projet SafeMoon, qui avait déjà fait face à des actions d'application de la SEC pour des allégations de fraude contre ses fondateurs.

Pourquoi c'est important

SafeMoon est un cas frappant pour comment une seule fonction publique par erreur peut compromettre tout le modèle économique d'un contrat. La fonction burn() en question était, dans sa forme prévue, une opération administrative routinière. L'exposer sans contrôle d'accès l'a transformée en un vidangeur universel de pool pour tout pool de liquidité détenant SFM.

Les leçons structurelles :

  1. Les modificateurs d'accès sur chaque fonction externe doivent être revus ligne par ligne, en particulier pendant les mises à niveau. Par défaut, toute opération privilégiée devrait être onlyOwner ou équivalent ; la charge de la preuve incombe au développeur pour justifier toute fonction qui est public ou external sans restrictions.
  2. Les permissions de fonction devraient être testées explicitement — chaque audit devrait inclure un test « n'importe qui peut appeler ceci » pour chaque chemin privilégié, pas seulement des tests fonctionnels du flux utilisateur prévu.
  3. Les mises à niveau récentes sont à haut risque pendant les 48-72 premières heures après le déploiement. De nombreux protocoles planifient maintenant des audits post-mise à niveau indépendants ou des primes de bug communautaires avec des paiements élevés pendant la fenêtre post-mise à niveau immédiate.

Le dénouement plus large de SafeMoon — combinant le piratage avec l'application de la SEC et la tokenomique sous-jacente étant largement considérée comme prédatrice — est également un schéma memecoin récurrent : les échecs de sécurité technique, la pression réglementaire et le scepticisme au niveau conception convergent souvent sur les mêmes projets en quelques mois les uns des autres.

Sources & preuves on-chain

  1. [01]halborn.comhttps://www.halborn.com/blog/post/explained-the-safe-moon-hack-march-2023
  2. [02]theblock.cohttps://www.theblock.co/post/223547/safemoon-liquidity-pair-compromised-in-8-9-million-hack
  3. [03]zellic.iohttps://www.zellic.io/blog/safemoon-exploit-explained/

Dépôts liés